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DESCRIPTION 

System and Method for In telligent Admixture 
and Delivery of Medications 

Background of the Invention 

This invention relates to methods and apparatus for 
5 intelligent admixture and delivery of intravenous drugs 
and for tracking and pre-delivery and post-delivery 
verification and recording of drug dosages however 
administered to patients. 

Although physicians, pharmacists, nurses, care givers 
10 and other health-care providers strive for error-free 
patient care, because of the complexity of modern medicine 
and the trend to minimize costs of delivery resulting in 
fewer and lower paid nurses, pharmacists, technicians and 
hospital employees, they frequently fall short of the 
15 mark. Indeed, the frequency of injuries from improperly 
formulated or delivered medication, (sometimes referred to 
as "adverse drug events") is rapidly increasing. 
Reduction of such injuries is an urgent need in light of 
the following statistic: researchers estimate that 180,000 
20 people die in the U.S. annually from adverse drug events. 
That number of deaths is the equivalent of 3 jumbo jet 
crashes every 2 days. The severity of the problem is 
compounded by a general lack of awareness, amongst both 
clinicians and the general public, that a problem even 
25 exists. L. Leape, Error in Medicine Journal of the 
American Medical Association, December 21, 1994, Vol. 272 
No. 23, p. 1851. 

Many of these adverse drug events result from errors 
in administering intravenous (IV) therapy. During any 
30 type of extensive hospitalization, a patient typically 
will receive some form of intravenous therapy because it 
is a fast and efficient route for the delivery of needed 
fluids and medications to a patient. The IV thus serves 
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as the preferred transport vehicle for the intermittent 
delivery of a drug. 

There are at least six basic classes of IV drugs: 
total parenteral nutrition (TPN) ; biotechnology (growth 
5 hormone for example); pain medication; continuous critical 
care medications; chemotherapy;, and intermittents . 
Intermittent IV drugs are typically delivered in 4-6 doses 
spread out over a given period, such as a day, although 
other dosing intervals can be encountered. 

10 Intermittent IV drugs can include, but are not 

limited to, antibiotics, antiemetics, H2 antagonists, 
steroids, and diuretics. IV drugs are typically prepared 
by the pharmacy or the manufacturer. Intermittent IV drugs 
represent one of the largest segments of medications 

15 delivered in a hospital. 

For ease of use, manufacturers of intermittent IV 
drugs typically package the drugs into vials such as 
single-dose vials, multiple-dose vials and custom-dose 
vials. A single-dose vial is defined as a vial whose 

20 entire contents is acceptable or intended for use as a 
single dose to a patient. A multiple dose-vial is defined 
as a vial containing several doses of a drug. A custom 
dose vial is defined as a vial containing an amount of 
drug that is not prepackaged in a single or multiple dose 

25 M unit of use" configuration. The custom-dose vial can be 
used where a patient requires more or less than the 
contents of a single vial. Custom dosing can dictated by 
factors such as, for example, the patient's body weight, 
the patient's body surface area, lab results, and other 

30 factors. 

Although clinicians may administer intermittent IV 
drugs quite often, the single- or multiple-dose vial 
configuration is typically not suitable for immediate 
intravenous delivery. This is because such drugs are 
35 normally packaged in a powdered, lyophilized or 
concentrated liquid form. Therefore, these drugs require 
conversion into a form more suitable for intravenous 



WO 99/10029 



PCT/US98/16813 



3 

delivery. This conversion of intermittent IV drugs into 
a form suitable for intravenous delivery is known as the 
IV admixture process or simply admixture. 

The admixture process normally includes a 
5 reconstitution step (if the medication is powdered or 
lyophilized, for example) and a dilution step. A 
pharmacist or technician ordinarily performs the admixture 
process after receipt of the prescription. This procedure 
is labor intensive and costly as well as fraught with 

10 potential error. Cohen MR, Davis NM. Medication Errors: 
Causes and Prevention , 1981. Schneider PJ, Gift MG. Cost 
of medication -related problems at a university hospital. 
Am J Health-Syst Pharm. 1995; 52:2415-18. Belkin, Who' s 
to Blame? It's the Wrong Question. N.Y. Times Magazine 

15 1997, p 28 - 

Reconstitution, in the case of a lyophilized or 
powdered drug, involves the pharmacist or technician 
injecting a small amount of sterile water or other agent 
into the drug vial and agitating the vial to thoroughly 

20 dissolve the drug. Repetition of this procedure under 
aseptic conditions is difficult. Additionally, constant 
exposure of the technician to drugs, many of which are 
toxic in concentrated form, represents a hazard to the 
technician's health. 

25 After reconstitution, a few of these drugs are now 

properly prepared for intravenous delivery. However, many 
drugs, after reconstitution, are too highly concentrated 
for immediate intravenous delivery. Such a concentrated 
solution could irritate or injure sensitive venous tissue. 

30 Thus, for most drugs, whether reconstituted or already 
available in concentrated liquid form, they must typically 
be diluted to prevent vein or tissue injury. 

Dilution can be performed using a number of different 
techniques. One such technique is carried out by 

35 reinserting a syringe into the vial containing the 
reconstituted drug and withdrawing the appropriate amount 
of drug into the syringe. The contents of the syringe are 
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then injected into a container holding a larger volume of 
solution commonly termed "diluent. " The amount of 
dilution is a function of the characteristics of the drug, 
dosage, concentration, and can also be based on a 
5 patient's weight or body surface area, as well as other 
factors. The dilution volume of a drug can range from 0 
ml up to a liter, or higher. 

One leading method of dilution involves injecting the 
contents of the syringe containing reconstituted 

10 medication into a flexible plastic bag sometimes known as 
a minibag. The minibag is a single use, sterile package 
containing an appropriate amount (e.g., 50- or 100- mi's) 
of diluent. The drug is typically added to the container 
through an injection port on the minibag. 

15 After the drug has been reconstituted and/or diluted, 

the pharmacist or technician affixes a preprinted patient- 
specific label to the bag. A pharmacist verifies the work 
and signs off on the label. The prepared minibag is then 
placed into refrigerated storage until delivery to the 

20 patient's location. 

Despite the verification made by the pharmacist, 
given the number of IV drugs required by a typical 
hospital daily, prescription, admixture and delivery 
errors can still arise. Errors can include, for example: 

25 improperly mixed drugs, dosages delivered too early, too 
late or not all, incorrect dosages ordered by the 
physician, lost tracking and billing, and costly drug 
waste. Indeed, a recent report notes that the observed 
error for compounding I.V. admixtures was 9%. Flynn et 

30 al., Observation! StVK*V of Accurapy Xn ComPQUndipq XrVt 
Admixture? at Five Hospital?, American Journal of Health 
Systems Pharmacia, Vol. 54, April 15, 1997, p. 904. Cohen 

MR, Davis NM. Confusing and (jflngeyoyt? medical 

abbreviations that should never be used . Penn Nurse. 1991; 

35 46(5) :4-5. Cohen MR, Davis NM. Pharmacy label mix-ups . 
Am Pharm. 1992; NS32 (1) : 26-7 . Cohen MR, Davis NM. 
Minimizing look-fllAke generic ma«-iffi>s. Am Pharm. 1994; 
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NS34 (3) :22-3. Cohen MR, Davis NM. More look -alike and 
sound-alike errors . Am Pharm. 1993; NS33(10):32. An 
incorrect drug delivery can result in increased patient 
stays and, in some cases, serious injury or death. 
5 Studies indicate the average hospital spends approximately 
$2.8 million annually due to hospital stays extended 
because of preventable medication errors. Bates DW, The 
Cost of A dverse Drug Events in Hospitalized Patients, JAMA 
Jan. 22/29, 1997; Vol.277 No. 4, 307-311. The national cost 
10 of these extended stays is estimated to exceed $4.2 
billion annually. Classen DC, Adverse Drug Eve nts in 
Hospitalized Patients , JAMA Jan. 22/29, 1997; Vol.277 No. 4, 
301-306. 

In addition to being labor intensive and error-prone, 

15 the admixture procedure just described is also wasteful. 
Often, the reconstituted and diluted drug has a short 
shelf life. Even with refrigeration, the solution should 
be discarded after its shelf life has expired, often 
within a few days after the admixture process. Thus, if 

20 a batch is prepared and subsequently not needed, it will 
likely be wasted. 

Furthermore, the use of minibags can lead to fluid 
overloading of the patient, particularly when multiple 
drugs are delivered to the patient intravenously. Because 

25 multiple drugs usually cannot be diluted simultaneously 
within the same minibag due to incompatibility potentials, 
each drug is diluted in its own minibag. This compounds 
the fluid overloading problem. 

Alternatives to the labor-intensive IV admixture 

30 process just described have undesirable properties as 
well. Convenience packaging systems represent an 
alternative falling into two major categories. The first 
is premix or frozen premix which is a manufacturer 
prepackaged drug that is stable when diluted or when 

35 diluted and frozen. This method still suffers from the 
fluid overloading problem discussed earlier. Also, even 
though the drug stability is extended, there is still a 
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limited shelf life. Additionally, this method suffers 
from the fact that manufacturers form strategic alliances 
with specific pharmaceutical companies and package that 
company' s "brand name" drug with their minibag, charging 
5 a premium in the process. This prevents a hospital from 
using the cheaper generic form of the drug should the use 
of a premixed minibag be desirable. 

A second alternative are minibags with vial adapters. 
A unit dose vial is attached to the minibag' s vial adapter 

10 and the vial adapter's seal is then broken. The nurse 
reconstitutes and simultaneously dilutes the drug by 
moving fluid from the minibag into the vial. This, 
category of minibags suffers from high cost, reduced 
ability to utilize generic drug substitutes, fluid 

15 overloading and the potential for drug waste. In 
addition, because nurses are not trained as pharmacists, 
the potential for errors are compounded when the pharmacy 
does not control the admixture process and nurses perform 
the so-called "mix and match" on the floor of the 

20 hospital. 

Referring now to Figure 1, we illustrate the multiple 
labor intensive and costly steps which must be carried out 
for the prior art manual IV admixture process. After a 
diagnosis 1, an order is written by the medical doctor 2. 

25 A pharmacist reviews the order 3, and approves and enters 
the prescription date 4. Prior to procuring the necessary 
materials 6, the pharmacist generates a pharmacy pick list 
of the required items 5. Typically a pharmacy technician 
then reconstitutes the drug 7 and dilutes the 

30 reconstituted medication into a minibag or other container 
8. Then the pharmacist checks the work of the 

technician, initials and places a label on the minibag 9 
before the minibag is stored for delivery 10. Steps 3 
through 10 represent the pharmacy admixture process 11. 

35 The minibags are thereafter distributed for delivery 

to the patient. Typically, the minibags are delivered to 
nursing stations in the general patient area 12 of the 
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hospital. The nurse or other clinician reads the 
patient's prescription and acquires the medication 13 from 
the administration station. The clinician checks and 
verifies that particular medications are correlated with 
5 particular patients as per the prescription 14. The 
medications are then infused into the patient 15. The 
final step is the logging of the dose delivery and time, 
denoted .as "manual information capture" 16. Steps 12 
through 16 represent the administration of medication 

10 process 17. 

In a effort to avoid the problems associated with the 
labor-intensive prior art IV admixture process, machine- 
aided reconstitution systems have been implemented. For 
example, various embodiments of a reconstitution and 

15 delivery system are disclosed in U.S. Pat. No. 4,410,321; 
U.S. Pat. No. 4,411, 662; U.S. Pat. No. 4,432,755; and U.S. 
Pat. No. 4,458,733. The systems disclosed by these 
patents, however, require that a number of operations be 
manually performed by the operator before infusion of the 

20 reconstituted medication can be performed. A automated 
system for reconstituting a drug and delivering the drug 
intravenously is disclosed in U.S. Pat. No. 5,116,316. 
Among other potential shortcomings, none of these 
conventional systems address the problem of preventing 

25 medication errors by verifying patient's prescription and 
drug dosage in the crucial gap between the preparation of 
the drug through the admixture process and its 
administration and delivery to a patient. 

Whether a drug is manually reconstituted and/or 

30 diluted through a manual admixture process or by machine 
as described in the above patents, the prepared IV drug is 
delivered into the veins of the patient at bedside. One 
conventional technique for delivery of the prepared IV 
drug is for a clinician to use a syringe and simply inject 

35 the prepared drug directly into a vein. However, to 
prevent vein irritation, in some instances it is necessary 
for the clinician to take several minutes to slowly inject 
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the contents of the syringe into the vein. Moreover, many 
drugs require larger dilution volumes and longer delivery 
times than can be practically provided for by manual use 
of a syringe, 

5 Another conventional technique for delivery of a 

prepared IV drug is through the use of a syringe pump. For 
such pumps, a pharmacist selects the appropriate size 
syringe, fills it, applies a label, attaches a specialized 
IV set, and delivers this to the clinician. The clinician 

10 loads the syringe into a syringe pump and starts the 
system. The syringe pump delivery system suffers from the 
costs associated with the labor required by the pharmacist 
in preparing the syringe and also does not have 
verification and recording features. 

15 One of the most popular conventional mechanized 

delivery systems is the peristaltic infusion pump which 
operates by squeezing the delivery line to force the 
prepared drug into a vein of the patient. Such a delivery 
system is illustrated in Figure 2. The system 32 includes 

20 three bags 36, 38, and 39, and a bottle or hard containers 
40, each of which contains a fluid to be delivered to the 
patient. The containers are coupled by flexible fluid 
flow conduits or tubes 42, 44, 46, and 48, the end of 
which are coupled to catheters or similar devices for 

25 delivering fluid to the patient. Each of the flow lines 
42 and 44 includes a conventional peristaltic infusion 
pump 50 which may be adjusted to deliver a specific 
volumetric flow to the patient. 

Peristaltic pumps exert a great deal of force on the 

30 IV line to effectuate pumping. After repeated squeezing, 
the line loses its round shape, becoming oblong from the 
pinching force of the peristaltic pump. Such a misshapen 
line may restrict flow. Thus some peristaltic pumps 
cannot deliver precise amounts of fluid due to this line 

35 distortion phenomenon. Finally, these pumps cannot control 
air within the line. Although these pumps may have air- 
in-line sensors at the output of the pump, these pumps 
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cannot detect bubbles at points upstream of the pump 
outlet and circulate them in a way so as to avoid air 
being pumped into the pump outlet altogether. The 
resulting air bubble alarms are a constant nuisance for 
5 nursing staff, especially considering that most of the 
detected bubbles are medically insignificant* 

Finally, hospital information systems are frequently 
less than adequate. Because pharmacists are overworked, 
they make mistakes and approve orders which they should 

10 not have. For example, they may approve: a prescription 
for a patient with known allergies to the prescribed drug; 
a prescription to a patient already receiving a different 
drug which is incompatible with the additional prescribed 
drug; a drug inappropriate to the patient's diagnosis, an 

15 inappropriate amount of a drug when lab values indicate 
new dosage levels. These mistakes are created by a lack 
of an integrated information system. 

Thus, there is a need for a drug delivery system, 
which will: automatically reconstitute and dilute 

20 medications; is capable of delivering precise amounts of 
fluids into a patient; can detect air bubbles and 
recirculate them before they are pumped outside of the 
pump outlet; can provide a bedside verification that the 
patient is receiving the correct drug (whether oral, IV, 

25 or topical) , diluted with the correct diluent, in the 
correct amount; at the correct time and correct route and 
will record and document all drugs administered to the 
patient . 

30 Smpmayy of Invention 

The present invention is directed toward a system and 
method for preparation and delivery of one or more IV 
drugs to a patient. The invention provides automated and 
controlled reconstitution, dilution and delivery of one or 
35 more medications for a given patient. 

In one embodiment, the invention utilizes a 
disposable cassette in conjunction with electronic 
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instrumentation to control the admixture (e.g., 
reconstitution and dilution) and delivery of the 
medication. 

The automated admixture and delivery system according 
5 to one embodiment of the present invention can include, 
for example, a drug database; a drug compounding and 
infusion device with data management capability; an input 
device, such as a barcode reader, for identification of 
drugs, patient and health-care provider at the patient's 
10 bedside; a communications port, and an internal printer. 

In a preferred embodiment, a barcode scan, the 
attachment of the drug vial, and a single press of a 
button will administer a dose. For more advanced 
operations, a user-friendly LCD message screen and 
15 controls walk clinicians through each step. Additionally, 
the instrument is designed to allow stable patient 
ambulation. 

The invention in one embodiment can include, for 
example, a drug database, a patient database, an input 

20 device such as, for example, a barcode scanner; a drug 
compounding/infusion device; a printer; software; a 
communications interface; and a computer or other 
processor-based controller for monitoring, controlling, 
metering conditions, administering drug doses and 

25 recording patient and drug information. 

In one embodiment, the drug database contains a list 
of medications in the individual hospital formulary. The 
database can further include an IV item template for each 
IV medication within the hospital formulary. The IV 

30 template allows the pharmacy to set drug delivery 
parameters according to drug manufacturer' s 
recommendations or other product standards. The 
parameters can include, for example, acceptable boundary 
limits which can restrict the clinician' s changes at the 

35 time of administration. 

The system in one embodiment utilizes a bar code 
scanning device for scanning the bar code labels of drug 
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vials , pharmacy prepared medications , manufacturer's drug 
packages , patient identification bands, and clinician 
identification badges. Other input devices and automated 
ID methods can also be used. 
5 In the preferred embodiment, the clinician scans the 

drug's bar code label during setup to identify the drug 
and dosage which is to be administered. In the event that 
a drug vial does not have a bar code on the label, in one 
embodiment the clinician chooses the drug and dosage to be 

10 administered from a "drop down" list, or menu, on the user 
interface. Alternative data entry methods may be used as 
well. The bar code scanner affords an easy and reliable 
means of identifying the drug to be delivered, the patient 
to which the drug will be infused and the clinician 

15 administering the drug. The system can be set up such 
that it will not allow a drug to be administered without 
having identified it via bar code scanning or other input 
means. The diluent, where appropriate, and its additives 
can also be identified via the bar code scanning or other 

20 input means. The system then links the identified drug 
with the IV template and verifies that the proper diluent 
and no contraindicated additives are in place. 

The automated admixture and delivery system ("AADS", 
also denoted as a bedside ^Sentry") includes a fluid 

25 delivery module which, through the use of a disposable 
cassette, can reconstitute, dilute and deliver unit dose 
drug vials. The Sentry can also deliver pharmacy prepared 
admixtures and primary solutions. One manner in which 
this is accomplished is by attachment through a luer port 

30 provided on the cassette. 

The IV templates from the drug database can be 
imported to and resident in each Sentry for reference 
during the delivery of each dose. Alternatively, the IV 
template can be stored on a remote database and accessed 

35 by the Sentry via a network or other communications 
connection. 
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After the medication, patient identification and 
clinician identification are entered, the Sentry may 
access the hospital pharmacy information system ("PIS") 
and the ADT/Billing database to obtain patient profile 
5 data for the particular patient being treated. Patient 
profile data can include the drug, diluent, dosage, time 
of administration, frequency of administration, route of 
administration, rate of delivery, physician name, and the 
volume to be delivered. Patient profile data can also 
10 include data such as known patient allergies, patient 
condition, other medication which the patient is on and 
any other information which may be material to determining 
whether administration of the proposed medication is 
appropriate. 

15 If the proposed drug event parameters pass the 

patient profile test, (i.e., what is scheduled to be 
delivered matches what has been prescribed and there are 
no contra-indications in the patient profile) the device 
allows the clinician to begin the delivery cycle. 

20 In one embodiment, the clinician may accept the 

pharmacy recommendations for drug delivery or may change 
a preset given by the IV template within boundary limits 
set by the pharmacy. If the clinician wants to change a 
preset outside the boundary limits, in one embodiment the 

25 Sentry alerts the clinician and may require that the 
Pharmacy be notified prior to delivery of the dose. By 
verifying the drug delivery event parameters to the 
patient profile, the present invention significantly 
reduces the probability of medication errors in the 

30 delivery of IV drugs. In addition, the Sentry may notifiy 
a nurse if any dose is due or to inform the nurse that one 
or more deliveries have been missed. 

The Sentry may store the drug delivery events 
associated with each administration. This information can 

35 be printed by the clinician either with the internal 
printer by selecting a print feature in the user interface 
or to a networked printer at the nurse's station. The 
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printing function enables the clinician to print the 
history of each dose for recording on medication 
administration records. The information can also be 
downloaded and used to update patient and pharmacy 
5 databases. 

Automatically reconstituting, diluting and delivering 
IV drugs to patients combined with pre-delivery 
verification of medications provides a reduction in 
medication errors, reduces the cost of IV supplies, 

10 reduces drug waste, reduces the labor required to admix 
and administer IV drugs, and also reduce the incidence of 
drug degradation prior to administration, all benefiting 
the patient. Predelivery verification of all drugs to be 
administered to a patient reduces medication errors, 

15 improves the quality of care, and lowers cost. 

Brief Description of the Drawings 

Figure 1 is a flow chart illustrating a manual 
admixture and delivery process. 
20 Figure 2 is a perspective view of a conventional 

peristaltic infusion pump used to deliver IV solution to 
a patient. 

Figure 3 is a diagram generally illustrating an 

automated medication management system according to one 
25 embodiment of the invention. 

Figure 4 is an operational flow diagram illustrating 

a method by which a patient treatment process performed 

according to one embodiment of the automated medication 

management system. 
30 Figures 5A and 5B are perspective diagrams of an 

automated medication management system according to one 

embodiment of the invention. 

Figure 6 is a flow diagram indicating the steps which 

are utilized for data entry compounding, confirmation of 
35 the identity of patient, and drug and recording and 

monitoring drug usage and delivery according to one 

embodiment of the invention. 
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Figure 7 is an exploded view of the automated 
medication management system according to one embodiment 
of the invention. 

Figure 8 is a detailed illustration of an example 
5 implementation of a cassette with vials mounted thereon 
according to one embodiment. 

Figure 9 is a diagram illustrating a vial mounted to 
a cassette spike according to one embodiment. 

Figure 10 is a cross-sectional view of a spike with 
10 a cap mounted thereon. 

Figure 11 is a diagram illustrating a downward view 
of how a cassette mounts on unit 75 according to one 
embodiment . 

Figure 12 is a diagram illustrating the vial loading 
15 mechanism according to one embodiment. 

Figure 13 is a diagram illustrating the vial loading 
mechanism according to one embodiment. 

Figure 14 is a diagram illustrating an example user 
interface for an automated medication management system 
20 according to one embodiment of the invention. 

Figure 15 is a diagram illustrating a perspective 
view of a cassette and a mounting structure for the 
cassette according to one embodiment of the invention. 

Figure 16 is a block diagram illustrating an example 
25 architecture for an implementation of automated medication 
management system according to one embodiment. 

Figure 17 is a diagram illustrating an example 
implementation of an automated health care facility 
according to one embodiment. 
30 Figure 18 is a diagram illustrating an example 

architecture for a data entry terminal according to one 
embodiment . 

Figure 19 is a diagram illustrating an example 
hardware and/or software implementation of elements of the 
35 invention according to one embodiment. 
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Figure 20 is a flow chart illustrating a system 
start-up overview according to one embodiment of the 
invention. 

Figure 21 is a flow chart illustrating a patient 
5 Identification routine according to one embodiment of the 
invention. 

Figure 22 is a flow chart illustrating a clinician ID 
routine according to one embodiment of the invention. 

Figure 23 is a flow chart illustrating a cassette 
10 loading and priming routine according to one embodiment of 
the invention. 

Figure 24 is a flow chart illustrating a vial 
attachment routine according to one embodiment of the 
invention. 

15 Figures 25, 26, 27, and 28 are a flow chart 

illustrating a non-IV programming routine according to one 
embodiment of the invention. 

Figure 29 is a flow chart illustrating door open 
request routine according to one embodiment of the 
20 invention. 

Figure 30 is a flow chart illustrating a hold 
delivery routine according to one embodiment of the 
invention 

Figure 31 is a flow chart illustrating a primary IV 
25 setup according to one embodiment of the invention. 

Figures 32A and 32B are a flow chart illustrating a 
vial port programming routine according to one embodiment 
of the invention. 

Figure 33 is a flow chart illustrating a drug to 
30 diluent incompatibility and special diluent requirement 
routine according to one embodiment of the invention. 

Figure 34 is a flow chart illustrating a network 
routine according to one embodiment of the invention. 

Figures 35A, 35B, and 35C are a flow chart 
35 illustrating a luer port programming routine according to 
one embodiment of the invention. 
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Description of the Preferred Embodiments 

The present invention is directed toward an automated 
admixture and delivery system. The Sentry according to 
the invention allows bedside admixture and infusion of IV 
5 medication as well as automated updates to patient and 
health care facility records and automated cross-checking 
for propriety of administration of the medication. 

Automated Med ication Management System 
10 FIG. 3 is a diagram generally illustrating an 

automated medication management system 300 according to 
one embodiment of the invention. Referring now to FIG. 3, 
the automated medication management system in this 
embodiment includes a control and management module 304, 
15 and a preparation and delivery module 308. The automated 
medication management system 300 can also include a data 
entry device 312 and internal data storage 316. 
Additionally, a communications interface 320 can be 
provided for communication to external entities such as, 
20 for example, an external database 332, an external server 
(not illustrated), or other remote or external device (s), 
networks, or entities. 

In the illustrated embodiment, preparation and 
delivery module 308 includes fluid delivery module 88 and 
25 cassette 77. Preparation and delivery module 308 provides 
automated reconstitution and dilution of medications, 
where required or appropriate. In one embodiment, 
cassette 77 incorporates one or more pressure conduction 
chambers, which are operated on by positive and negative 
30 pneumatic pressure supplied by fluid delivery module 88 to 
perform reconstitution, dilution and metering of the 
medication. Fluid delivery module 88 is controlled by 
control and management module 304 . 

Control and management module 304 determines the 
35 appropriate admixture process to be followed for the 
subject medication and controls fluid delivery module 88 
to reconstitute and/or dilute the medication as 
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determined. Control and management module 304 also 
controls delivery of the medication to the patient. 

Control and management module 304 can receive data to 
determine the appropriate admixture process from one or 
5 more sources. These sources can include, for example, 
data entry module 312, external sources via communications 
interface 320 and internal data storage 316. Control and 
management module 304 can also use data from such sources 
to determine the appropriateness of the medication to be 

10 delivered to the particular patient. 

Data entry device 312 can comprise one or more 
devices for inputting data such as, for example, a bar 
code reader, a keypad or keyboard, a touch-screen display, 
a magnetic card reader or other data entry device. The 

15 data entered using data entry device 312 can include, for 
example, patient data, medication data, clinician 
identification and other pertinent or related data. 
Entered data can be used for control and management of the 
delivery system and stored for later recall. 

20 In one embodiment, data entry device 312 includes a 

bar code reader which can be used to scan bar codes on the 
medication to be administered to the patient. The bar 
code reader can also be used to scan bar codes indicating 
information such as, for example, patient ID's or other 

25 patient information from the patient's chart, wristband or 
other source; the clinician's ID (e.g., from an ID is 
encoded on a badge) and other information. In one 
embodiment, the combination of a bar code reader and a 
keyboard, for example, allows entry of scanned and 

30 manually entered data. 

Internal data storage 316 can comprise one or more 
data storage devices for internally storing pertinent 
information. In one embodiment a medication administra- 
tion record is stored internally for later retrieval or 

35 download. In another embodiment, an internal database can 
be included for storing information such as patient 
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information, medication information and other pertinent 
information. 

Communication interface 320 can be used to 
communicate with external devices such as, for example, 
5 external databases, servers, controllers, or other 
entities. In one embodiment, communication interface is 
a network interface for connection to, among other network 
entities, a network database comprising information such 
as medication information, pharmacy information, patient 
10 information and other inf ormation. 

In one embodiment, the system cross checks the 
medication to be administered against data contained in 
one or more databases to provide a safeguard against 
administration of improper medications or at improper 
15 dosage levels. In this embodiment, control and management 
module 304 checks the intended medication against 
information in the one or more databases and enables 
delivery only after verification that the particular 
patient is to receive a prescribed drug in the correct 
20 amount, with the proper diluent if required, at the proper 
time. Because this system provides a safety check before 
delivery of a drug, errors in delivering the incorrect 
drug or the incorrect amount are reduced. 

Such a safety check can be performed any time after 
25 the prescription is entered and ideally, before the 
prescribed medication is administered to the patient. For 
example, the check can be performed at the time of 
prescription entry, before the prescription is prepared by 
the pharmacy, or before administration of the medication 
30 to the patient. 

Having generally described an example architecture of 
the automated medication management system 300, its 
operation is now described in an example environment. The 
automated medication management system, according to the 
35 present invention, is suitable for use' in numerous 
environments in which medications are delivered to a 
patient. Embodiments of the invention are now described 
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in terms of one such environment. This description is 
provided to facilitate discussion of the invention in an 
example operational environment and is not intended to 
limit the invention to application in such an environment. 
5 In fact, after reading this description, it will become 
apparent to one skilled in the how to implement the 
invention in numerous alternative environments. 

Figure 4 is an operational flow diagram illustrating 
the operation of automated medication management system 

10 300 in an example environment. In a step 404, a patient 
is evaluated by a health care professional such as, for 
example, a physician. The health care professional 
determines whether any medication is required or 
recommended to treat the patient's condition. If so, the 

15 appropriate medication, dosage and dosing interval are 
determined for that patient. In one embodiment, the 
physician can access a prescription analysis package that 
aids in the selection of the appropriate medication. This 
clinical decision-making database can be used to check 

20 diagnosis, patient demographics, known allergies, and 
current lab values to assist the physician in selecting 
the optimal medication. 

In a step 408, after the health care professional 
determines which medication is appropriate to treat the 

25 patient's condition, a prescription is generated by that 
health care professional. The prescription is then 
delivered to and filled by a pharmacy, such as, for 
example, the hospital pharmacy. In one embodiment, the 
prescription is hand carried by a clinician or delivered 

30 by other manual means to the pharmacy so that it can be 
filled. 

In an alternative embodiment, the physician order for 
the prescription can be entered into the data entry 
terminal and the prescription can then be electronically 
35 or otherwise automatically delivered to the pharmacy such 
as, for example, by electronic mail or by other electronic 
means. In yet another embodiment, the prescription can be 
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entered using data entry device 312. The prescription can 
then be transferred to the pharmacy or other entity 
electronically via communications interface 320. 

In an embodiment where the prescription information 
5 is entered electronically and stored in a database, the 
physician order can be automatically distributed to the 
pharmacy as it is entered into the database. 
Alternatively, the prescription can be subsequently 
retrieved from the database and sent to the pharmacy 

10 either automatically or by a health care professional. In 
other words, through the use of networking or other 
communication techniques, the delivery of the prescription 
to the pharmacy can be fully or partially automated. 

Upon entry of a prescription, or prior to filling the 

15 prescription, the prescription information can be checked 
against one or more databases to determine the propriety 
of the prescription. If it is determined that the 
prescription as written or entered into the system may be 
inappropriate, steps are taken to warn of the error and 

20 allow the prescription to be verified or altered before 
administration of the prescribed medication. This process 
is described in greater detail below with reference to 
several embodiments. 

In a step 412, pertinent patient data useful for the 

25 administration of the medication is entered into the 
automated medication management system 300. In one 
embodiment the information is stored in a patient 
database, and can be downloaded from the patient database 
to automated delivery system 300. This too can be done by 

30 a hard-wired or a wireless communication link. In one 
embodiment, the patient database or a duplicate copy 
thereof is resident in automated medication management 
system 300, allowing direct access of patient data. 

In one embodiment, the identification of the patient 

35 is entered into automated delivery system 300, and this 
identification is used to retrieve one or more data 
records from the one or more databases. The patient data 
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can be entered by the clinician using data entry device 
312. Where data entry device 312 is a keypad, touch- 
screen display, keyboard, or other terminal-like device, 
the information is simply manually entered by the 
5 clinician. Where data entry device 312 includes an 
automated code reader such as a bar code scanner or 
magnetic reader or other code- or data-reading device, 
pertinent patient information can be scanned in using bar 
codes, magnetic stripes, voice recognition or other coded 

10 materials. 

In one embodiment, the patient data entered into the 
automated medication management system 300 can include 
patient identification as well as other information 
pertaining to the patient. 

15 In order to identify the health care professional to 

automated medication management system 300, his or her ID 
(identification) can also be entered. The ID can be a 
name, employee number or other identifying code or 
designation. In one embodiment, the ID can be entered by 

20 using a bar code or magnetic scanner to scan an 
identifying code provided by the health care professional. 
Such a code can be provided, for example, on the health 
care professional's badge. Additional security can be 
provided by requiring the health care professional to 

25 enter a PIN (personal identification number) or other 
password associated with his or her ID. Additionally, 
manual entry of ID and PIN can be provided by keypad or 
touch screen display. Alternative data entry means can 
also be utilized for identification. 

30 In a step 416, the prescribed medication which has 

been received from the pharmacy is loaded into automated 
medication management system 300. This medication may be 
unprepared in that it requires reconstitution and/or 
dilution before it can be administered to the patient. 

35 The automated delivery system can access information 

in a pharmaceutical database to determine whether 
reconstitution and/or dilution are required for each of 
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the medications entered as well as the rate of delivery 
for the prepared medications. In one embodiment, control 
and management system 304 determines the proper admixture 
process and controls preparation and delivery module 308 
5 for the admixture and infusion of the prescribed 
medications. Control and management system 304 may 
utilize internally or externally stored information such 
as, for example, IV templates to determine the correct 
reconstitution and dilution levels. 

10 For example, control and management system 304 can 

look up a prescribed medication in a pharmaceutical or 
other database and determine from the database the 
appropriate reconstitution and dilution levels. 
Alternatively, this information can be dictated by the 

15 prescription and either manually entered or automatically 
downloaded to the automated medication management system 
300. 

In one embodiment, the medication information can be 
entered by data entry module 312 such as by the operator 

20 keying in the identification information or utilizing a 
bar code scanner or other code reader to read a bar code 
label on the medication container. The scanner can be a 
hand-held scanner connected to automated medication 
management system 300 via a wired or wireless interface. 

25 In another embodiment, a bar code scanner or other 

code reader is integrated into the system such that the 
bar code label or other coded information is read from the 
medication vial when the vial is loaded into the system. 
As would be apparent to one of ordinary skill in the art 

30 after reading this description, other data entry 
techniques can be used as well. 

The manner in which medicine is loaded into automated 
medication management system 300 is described in detail 
below. As described below, safeguards are provided to 

35 ensure that the chances of accidental exposure of the 
medication to the health care professional are minimized. 
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Various safeguards are provided to ensure that the 
appropriate medications are being loaded into the 
automated medication management system 300. In one 
embodiment, the clinician enters an identification of the 
5 medication into automated medication management system 300 
and automated medication management system 300 verifies 
that this is the correct medication as prescribed to the 
patient by looking into the patient's database, or into a 
prescription database for example. 

10 Automated medication management system 300 can also 

check various prescription, medication and patient 
information to ensure that the proper medication is being 
administered to the proper patient and at the correct 
dosage, and dosing interval. 

15 For example, automated medication management system 

300 can check the patient database to determine whether 
the prescribed medications conflict with any information 
in the patient database such as patient allergies, patient 
conditions, patient demographic information, or other 

20 information which would indicate an actual or possible 
incompatibility with the prescribed medication; current 
patient drugs which may be incompatible with the 
prescribed medication; whether the patient has already 
been prescribed medication to treat the condition to 

25 perform duplicate therapy checking; or other concerns 
which may be raised as a result of the prescription of the 
medication to the patient based on the stored information. 
If a concern or incompatibility does exist , a flag can be 
raised to the clinician via a warning sound, indicator 

30 light, message, or other display or indication on the 
automated medication management system or by a 
transmission of a message or signal to an appropriate 
location. 

Automated medication management system 300 can also 
35 check a pharmaceutical database which contains information 
pertaining to the various medications. The pharmaceutical 
database can include one or more databases with 
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information regarding drug interaction precautions and 
other drug incompatibility problems, as well as drug 
parameters, and IV template information. The information 
in this database can be stored locally in the automated 
5 medication management system 300 (either as original data 
or a duplicate copy) , or stored remotely and accessed by 
automated medication management system 300 prior to 
administration of medication. 

As an example of a check which may occur consider a 

10 scenario in which a patient suffers from high blood 
pressure. As is well known, there are certain medications 
which may further aggravate or compound the high blood 
pressure problem. If such a medication is prescribed for 
the patient, control and management system 304 can check 

15 the medication against known conditions which the 
medication may aggravate, determine from the patient 
database whether the patient suffers from any of these 
conditions, and, if so, raise an appropriate flag or 
warning. 

20 In another example, other information such as either 

the dose or dosing interval of the medication or feedback 
on a patient's condition from a laboratory can be checked 
against the patient 1 s age, weight, physical condition, or 
other factors to determine whether the prescription is 

25 within acceptable bounds ; As such, a more fail-safe 
mechanism is provided as a cross check against the 
prescription of medication which may not be ideally suited 
to the particular patient given his or her condition. 

This error-checking process can be similar to, or 

30 even duplicative of, the error checking process described 
below with reference to a physician order entry of the 
original prescription. One feature added at this stage, 
however, is the ability to verify the identification of 
the patient to whom the medication is actually going to be 

35 administered just prior to administration. 

In one embodiment, delivery of the medication is not 
allowed to proceed if the error-checking process 
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determines that it may be inappropriate to administer the 
medication as prescribed. In one embodiment, the halted 
system can be overridden by a health care professional 
with the appropriate authorization clearance level. 
5 In one embodiment, if a warning flag is raised or the 

system halted, the condition can be overridden by the 
appropriate health care professional where that 
professional deems that the prescribed medication is 
appropriate under the circumstances despite the warning. 

10 For example, the physician prescribing the medication may 
note that it does aggravate a condition such as high blood 
pressure but may decide that the patient's need for the 
medication outweighs the risk in administering the 
medication and may therefore consider that the prescribed 

15 medication is still appropriate. In this situation, the 
physician simply overrides the alarm and allows the 
delivery to proceed. In one embodiment, the physician may 
do a preemptive override at the time of making the 
physician order in advance of receiving the actual 

20 warning. This override can be stored in the database so 
that the alarm is avoided. Additionally, occurrences of 
alarms and overridden alarms can be recorded for 
historical and statistical purposes. 

In one embodiment, multiple levels of authorization 

25 are accommodated. Thus, different users may have 
different levels of "clearance" to perform operations such 
as prescribe medication, override alarms, administer 
medication, or perform other operations. For example, a 
user ID or other code may be required for the health care 

30 professional to operate the automated delivery system as 
well as a password or PIN. Different users can be 
provided with different levels of security, authorization, 
or access. For example, in this environment, a physician 
may be provided with the ability to enter a prescription 

35 and override a drug warning, whereas a nurse or other 
clinician may not. As would be apparent to one of 
ordinary skill in the art after reading this description, 
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differing levels of hierarchy and various authorization 
levels can be provided based on the goals of the 
administration of the delivery system and the composure of 
the infrastructure in which it is implemented. 
5 In a step 420 , the medication is prepared for the 

patient. In this step, where reconstitution and/or 
dilution are required, preparation and delivery system 308 
performs these operations. In one embodiment, as 
described below, the admixture process takes place in 
10 cassette 77 where the medications are properly 
reconstituted and/or diluted as required. 

As discussed above, control of the admixture process 
is undertaken by control and management system 304 to 
ensure proper admixture is performed. Additional details 
15 on the manner in which the admixture process is performed 
according to one or more embodiments are provided below. 

In a step 424, the prepared medication is delivered 
to the patient by preparation and delivery unit 308. The 
medication is properly metered such that the patient 
20 receives the correct dose over the defined period of time. 
The system can be set to provide alarms when air is 
present in the delivery lines. 

In a step 428, one or more databases are updated to 
indicate that the patient has been administered the 
25 medication. This information can include information such 
as the medication administered, the dose administered, the 
date and time on which the medication was administered, 
and other important information. In one embodiment, this 
data is stored in an internal database (e.g., data storage 
30 316) which can then be downloaded to an external database 
for record-keeping or archival purposes. In this 
embodiment, the internal database can be used as a history 
log recording a medication administration record performed 
by automated medication management system 300 over a 
35 period of time. 

Thus, automated medication management system 300 can 
be transported from patient to patient for delivery of 
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medication and keep an internal log of the deliveries and 
surrounding information. The information stored in the 
history log can be printed or displayed to provide health 
care professionals with information regarding recent 
5 transactions. 

In alternative embodiment s, the automated medication 
management system 300 can be more permanently connected or 
networked to an external database such that an internal 
log need not be kept to update patient, hospital, 
10 medication, or other records. Information from automated 
medication management system 300 can also be provided to 
accounting and other departments for billing, inventory, 
statistics collection, or other record-keeping purposes. 

15 Example Implementation of Automate d Medication Management 
Sygt^m 300 

An example implementation of automated medication 
management system 300 is now described with reference to 
Figures 5A and 5B. After reading this description, it 

20 will become apparent to one skilled in the art how to 
implement automated medication management system 300 
utilizing alternative configurations. A detailed view of 
a bedside control and delivery unit 50 is shown in Figures 
5A and 5B according to one embodiment. The Bedside 

25 control and delivery unit 50 includes a head unit ' 75 
mounted on a base plate 77. The base plate 77 rests on 
the base assembly 76. Base assembly 76 includes side 
doors 80 which pivot open to reveal shelves 81, useful for 
storing medical paraphernalia. Also attached to base 

30 assembly 76 are IV poles 72 and a caster base 82. 
Ambulation bar 73 attaches to base assembly 76 through 
supports 83. The combination of caster base 82 and 
ambulation bar 73 allow stable patient ambulation. 

Head unit 75 includes cassette 77 through which 

35 fluids and air are transported by fluid delivery module 88 
(not shown) . Cassette 77 is preferably disposable and not 
re-used for other patients or for delivery of subsequent 
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medications to the same patient. Vial loading spikes 118 
are disposed along the top of cassette 77. When cassette 

77 is mounted in unit 75, drug vials 85 may be pierced by 
spikes 118 so that fluid from within cassette 77 may be 

5 forced into vials 85 to reconstitute the drug contained 
therein. Hinged door 86 covers vials 85 in ordinary use. 
A clinician mounts cassette 77 by opening outer door 

78 and inner door 87 (not shown) and positioning cassette 
77 against fluid delivery module 88. The clinician then 

10 closes inner door 87 and outer door 78. In one embodi- 
ment, inner door 87 provides the necessary force to keep 
cassette 77 stationary against fluid delivery module 88 so 
that fluid delivery module 88 may pneumatically operate 
cassette 77. Outer door 78 serves as a safety check 

15 because if inner door 87 is opened, cassette 77 is 
disabled or otherwise prevented from contacting other 
patients. After inner door 87 is opened, fluids in 
cassette 77 could commingle and flow to the patient which 
can be hazardous. A disablement is provided to prevent 

20 this condition. Because cassette 77 is disabled once 
inner door 87 opens, a warning is displayed to the 
operator when outer door 78 is opened to prevent 
unnecessary disablement. 

Bar code reader 70 or other data entry device can be 

25 used to scan the bar codes or other coded label on vials 
85, pharmacy-prepared labels, manufacturer-prepared 
labels, and can also scan coded patient, physician and 
clinician identification. After the clinician enters or 
scans this information, unit 75 accesses drug database 92 

30 which can be internal or an external database. Bedside 
control and delivery unit 50 verifies that the particular 
patient has been prescribed the particular drug being 
administered and that the diluent and additives in bag 89 
are proper by accessing stored information such as, for 

35 example a patient profile contained in the patient 
database and the medication information stored in a 
pharmaceutical database. In addition, Bedside control and 
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delivery unit 50 provides an alarm for dosages which 
exceed safe levels to be delivered by Bedside control and 
delivery unit 50. 

Referring now to Figure 5b, a back view of unit 75 is 
5 illustrated. Because in this embodiment Bedside control 
and delivery unit 50 contains a substantial amount of 
electrical and electro-mechanical hardware , a means for 
dissipating heat resulting from this hardware is provided. 
Because a fan could result in noise bothersome to 

10 patients, one embodiment of Bedside control and delivery 
unit 50 employs a large heat sink 91 instead. Other heat 
dissipation means can be used. 

Also shown in Figure 5b, a printer 90 can be utilized 
to print records of medications delivered to the patient. 

15 Rather than requiring a clinician to manually keep records 
of administered medications, in one embodiment as 
described above, Bedside control and delivery unit 50 
records all drug events and can then print those events on 
printer 90 or download them to a database. Alternatively, 

20 the system can access a remote printer at the nurse's 
station via a network connection. In one embodiment, a 
caster base 82 or other rollers are provided to facilitate 
ambulation of the system. 

Figure 6 is a block diagram generally illustrating 

25 the use of automated medication management system 300 for 
administering medication to a patient in the embodiment 
described in Figures 5A and 5B. To begin the process, in 
a step 94, the system is brought to the patient's bedside. 
A cassette 77 is loaded if IV delivery is required. In 

30 one embodiment, a network connection is established by 
powering up the system. 

In a step 95, The patient's identification is scanned 
through the use of scanner 70, so that the system can be 
set up to support the specific patient and can check that 

35 the medication is actually prescribed for the identified 
patient. At step 96, the clinician's identification can 
be scanned as well and his or her password entered. This 
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acts as a security measure, to help prevent unauthorized 
personnel from altering drug delivery parameters or 
administering drugs without authorization. Alternatively 
the identification can be entered manually or via other 
5 data-entry means. 

As discussed above, in one embodiment the system uses 
the patient identification to check one or more databases 
as a cross check against the medication being provided to 
the patient in the instant infusion. 

10 After completion of the above, the system is ready 

for use as shown in step 97 . Now, the clinician may bring 
the drug to be administered to the patient's bedside for 
installation in automated medication management system 300 
at step 98. The drug is identified, such as for example 

15 by barcode scan at step 99. If the drug does not have a 
barcode label, the clinician may identify it through a 
list imported from the network 71 or through a drug list 
residing in memory within the system or by manual data 
entry. 

20 In step 100, the system verifies that the identified 

drug, dosage, patient name, time of delivery, and route of 
delivery correspond with prescription information on file. 
Should all information be correct, in step 101, the system 
proceeds with its operation. 

25 The clinician is notified of inaccuracies and asked 

to correct them if he or she still wishes to proceed. 
However, in certain circumstances, such as for example 
where the requested dosage exceeds the maximum allowed 
level, the system does not allow or approve delivery. In 

30 one embodiment, the system can be overridden with the 
appropriate authorization. 

At step 102, the clinician loads the desired drug 
vial 85 onto the cassette 77. For medications which are 
not delivered through cassette 77, the user enters the 

35 information into bedside control and delivery unit 50 so 
that the drug event data can be transferred to other 
databases within the hospital. 
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In step 103, the system reconstitutes, dilutes, and 
infuses cassette-prepared medications. After infusion, 
the cassette is rinsed so that no incompatible drug 
reactions occur upon the next drug delivery cycle. 
5 Finally, at step 104, the system records all delivered 
drug events, whether administered through the cassette or 
through other routes. That information may be 

transmitted to other databases within the hospital. 

Figure 7 is a diagram illustrating a simplified 

10 exploded view of head unit 75 according to the example 
implementation illustrated in Figures 5A and 5B. Fluid 
delivery module 88 pneumatically operates cassette 77 so 
as to reconstitute vials 85. Inside unit 75 is the 
control and management unit 304 which controls overall 

15 operation of Bedside control and delivery unit 50, using 
software 67 and database 92. 

A battery 105 or other alternative power source 
allows mobile use and uninterrupted operation in case of 
power failure. Bar code scanner 70 is shown reading a 

20 patient's identification bar-code on a wristband. Such 
information will eventually be recorded by Bedside control 
and delivery unit 50 as part of all drug events monitored 
or delivered by the present invention. 

Control and management module 304 controls fluid 

25 delivery module 77 so as to provide automated 
reconstitution, dilution, infusion, and rinsing of 
medications delivered through cassette 77. Module 304 
also works to communicate with database 92 for 
verification and recording of all other medication 

30 deliveries. Fluid delivery module 88 operates on cassette 
77 so that fluids and air can be moved through cassette 77 
without any contact with fluid delivery module 88. In one 
embodiment, module 304 includes an X86 processor-based 
system such as, for example, a 386 CPU and associated 

35 peripherals. 
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Example Implementation of Cassette 77 

Figure 8 is a detailed illustration of an example 
implementation of a cassette 77 with vials 85 mounted 
thereon according to one embodiment of the invention. The 
5 components and relevant materials of the cassette 77 
according to one embodiment are listed in the table below. 
Alternative materials can be used to implement cassette 
77. 



10 


COMPONENT 


MATERIAL 




Valves 112 


Santoprene 281-64 


15 


Mixing chamber 
diaphragm 


Santoprene 281-64 


20 


Delivery chamber 
diaphragm | 


oautoprene zoi-oi 


Control Wheel Seat 
Insert 


Santoprene 281-64 


25 


Control Wheel Seat 
Base 


Pro Fax PD-626 from 
Himont 




Midbody 113 


Monsanto Lustran ABS 
248-2002 (white) 


30 


Control Wheel 600 


Monsanto Lustran ABS 
248-2002 (white) 


Front Cover 111 


BASF Terlux 2812TR 




Rear Cover 111 


BASF Terlux 2812TR 


35 


Spikes 118 


Monsanto Lustran 248- 
2002 (white) 




Spike Covers 126 


Polyethylene 


40 


Luer Lock Cap 


Polyethylene 


Vented Air Cap 


Polyethylene 



The cassette 77 according to this embodiment is now 
described. The cassette is comprised of a mid-body 113 
45 which contains the fluid delivery pathways and seats for 
the diaphragms and valves. Midbody 113 is ultrasonically 
welded to the two covers which sandwich the diaphragms, 
valves and control wheel 110 in an assembly. Spikes 118 
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are separately molded pieces which are also ultrasonically 
welded to midbody 113 and inner and outer covers 111. 
Tubing is bonded to the cassette for both the proximal 117 
and distal ports 115 and air input port 116. Standard set 
5 components make up the remainder of the administration 
set. 

The cassette and set are packaged and sterilized to 
provide a sterile fluid pathway. All cassette and set 
materials have been tested for biocompatibility and meet 

10 ISO 10993 standards. Caps 126 on the three vial spikes 
118, the luer port 108, the proximal tubing port 117 and 
the distal tubing port 115 provide sterile barriers so 
that the set and cassette assembly is a closed loop system 
and is preserved sterile when it is removed from the 

15 package. Once the cassette 77 is loaded in the Bedside 
control and delivery unit 50, the vial spikes 118 and luer 
port 108 are maintained sterile by keeping the caps 126 in 
place until the time of use for each respective port. 

On both sides of cassette 77 are rigid plastic covers 

20 111 covering cassette 77. Pressure conduction chambers 
109 and 110 have windows fashioned on inside cover 111, 
thus exposing the flexible diaphragm for each chamber. 
The valves 112 are formed in an analogous fashion. Fluid 
delivery module 88 can apply positive or negative pressure 

25 to the pressure conduction chambers 109 and 110. 

When applied to the flexible diaphragm covering 
pressure conduction chambers 109 and 110, the pressure 
acts to draw fluid into the chambers or expel fluid out of 
the chambers. The valves 112 are controlled by DC motors 

30 which are cam actuated. The cam actuation opens and 
closes valves 112. In this way, through a combination of 
positive and negative pressure applied to the chambers 109 
and 110, and the actuation of valves 112, fluid delivery 
module 88 can pump fluid from inlet line 117 into the 



WO 99/10029 PCT/US98/16813 

34 

vials 85, reconstitute the medicine therein, and withdraw 
the fluid from the vials 85 back into chamber 109 . 
Repetition of fluid movement into a vial 85 and back into 
chamber 109 assures that the medicine is entirely 
5 reconstituted. This fluid can then be precisely diluted 
in chamber 109 which is denoted the mixing chamber. 
Chamber 110 is denoted the metering chamber because the 
fluid is precisely measured and pumped into outlet line 
115. Movement of fluids in this fashion is disclosed in 

10 U.S. Patent Nos. 4,848,872; 4,778,451; 4,786,800; 
4,804,380; 4,816,019; 4,826,482; 4,976,162; 5,088,515, 
5,178,182, 5,193,990, 5,241,985, 5,353,837; 5,364,371; 
5,401,342, which are incorporated herein by reference. 

Fluid delivery module 88 also possesses acoustic 

15 volume sensing technology whereby a loudspeaker transmits 
sound waves into an acoustic volume sensing (AVS) chamber 
of fluid delivery module 88 and thereby measures the 
resonant frequency of the AVS chamber. The AVS chamber 
of the fluid delivery module is in communication with 

20 chamber 110 of the cassette. By measuring the volume of 
air in the AVS chamber through resonant frequency 
monitoring, the volume of fluid within chamber 110 can be 
calculated by a microprocessor contained within fluid 
delivery module 88. In addition, should air bubbles be 

25 entrained in the fluid within the pressure conduction 
chamber 110, these bubbles will be detected by AVS. The 
microprocessor will monitor for the presence of air 
bubbles and will not pump liquid containing bubbles from 
the cassette 77 to the patient. Instead, the 

30 liquid/bubble mixture is either pushed back to the fluid 
source 89 or will be kept in chamber 109 until it is safe 
to expel the bubble to 89. Air can enter vials 85 through 
the air channel 116, preventing a vacuum condition from 
occurring as vials 85 are drained into mixing chamber 109. 
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Acoustic volume sensing technology is set out in U.S. 
Patent Nos. 5,211,201; 5,349,852; 5,526,844; 5,533,389, 
which are incorporated herein by reference. 

Fluid within cassette 77 is pumped into vials 85 from 
5 mixing chamber 109. The means by which vials 85 are 
attached to cassette 77 is illustrated in Figure 9 
according to one embodiment. Vial 85 is held by clamp 
125, part of a vial-loading mechanism discussed below. 
Spike 118 has a lumen 119 through which fluids and air may 

10 pass into cassette 77. When vial 85 is mounted on spike 
118, the sharpened end of spike 118 pierces elastic seal 
120 of vial 85 so that lumen 119 is now in contact with 
contents of vial 85. The elasticity of seal 120 ensures 
an airtight seal about spike 118. Clamp 125 holds vial 85 

15 stationary during system operation. When vial 85 is not 
mounted, a protective cap 126 covers spike 118 to maintain 
sterility and to protect users as illustrated in Figure 
10. 

A downward view illustrating how cassette 77 mounts 
20 on unit 75 according to one embodiment is shown in Figure 
11. Spikes 118 and luer port 108 are shown without any 
connections. To mount cassette 77, outer door 7 8 is 
pivoted open in one embodiment. Inner door 87 pivots at 
its bottom to swing open. After cassette 77 is placed 
25 against fluid delivery module 88, inner door 87 is pressed 
shut. In one embodiment, spring-loaded cams 128 are 
pushed aside as door 87 closes. When inner door 128 is 
fully closed, cams 128 return to their locking position. 
In this way, inner door 87 is held with sufficient force 
30 against fluid delivery module 88 so that pneumatic drivers 
can apply positive and negative pressure against the 
diaphragms of chambers 109 and 110 without leakage of 
pressure. 
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Figure 15 is a diagram illustrating a perspective 
view of a cassette 77 in proximity with a portion 1532 of 
automated medication management system 300 designed to 
accept cassette 77. As illustrated in figure 15, one or 
5 more openings 1534 are provided to allow FMS and/or AVS 
actuation to to control the operation of Pressure 
conduction chambers 109 and 110 on cassette 77. Actuators 
1538 are used to control the operation of valves 112. 

Example implementations of cassette 77 are disclosed 

10 in in application numbers, titled "System, Method ' and 
Cassette for Mixing and Delivering Intravenous Drugs, " and 
"Cassette for Intravenous-Line Flow-Control System.'' 
These documents are incorporated herein by reference to 
illustrated one example implementation of a cassette 77. 

15 Alternative implementations of cassette 77 can be used in 
conjunction with automated medication management system 
300, including numerous alternative currently commercially 
available cassettes . 

20 Vial Loading Me chanism 

Figures 12 and 13 illustrate a vial loading mechanism 
according to one embodiment of the automated medication 
management system 300. As would be apparent to one of 
ordinary skill in the art after reading this description, 
25 alternative vial loading mechanisms can be implemented. 

In order to connect the vials 85 to the cartridges 
77, the membrane seals 120 of vials 85 are pierced. The 
clinician accomplishes this by inverting each vial 85 and 
lowering the vial 85 onto the spike 118 so as to pierce 
30 seal 120 with spike 118. 

With reference to Figures 12 and 13, to prevent the 
clinician from accidentally contacting the spikes 118 and 
injuring oneself, a vial loading mechanism, indicated 
generally by the reference numeral 200 can be provided. 
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Vial loading mechanism 200 includes a panel assembly 202. 
Panel assembly 202 has an upper portion 204 and a recessed 
portion 206. 

In front of recessed portion 206, a plurality of 
5 holders 207 are provided. Each holder 207 includes an 
outer holding arm 208 and an inner holding arm 210. The 
outer holding arm 208 includes a proximate end 212 
adjacent to the panel assembly 202 and a distal end 214. 
The distal end 214 includes an arcuate holding portion 

10 216. A tang 218 extends inwardly from a lower part of one 
side of the arcuate holding portion 214. A groove 220 is 
provided in an upper portion of this side. A cutout 222 
is provided in the lower part of the opposite side of the 
arcuate holding portion 214. The groove 220 allows the 

15 head of the vial 85 to fit into the arcuate holding 
portion 216 and the tang 218 supports the head of the vial 
85. A rectangular cutout or slot 224 is provided in the 
outer holding arm 208 and is defined by a pair of opposing 
walls 226 and an end 228. 

20 The inner holding arm 210 is pivotally connected to 

the opposing walls 226. The inner holding arm 210 
includes a main body 230 with a sleeve 232 at one end and 
a penannular holding portion 234 at an opposite end. Both 
the arcuate holding portion 216 and the penannular holding 

25 portion may have corrugated, rubber on other friction- 
prompting inner surface to enhance the frictional 
engagement between the vial 85 and holding portions 216, 
234. A projection 236 extends in a generally lateral 
direction from the holding portion 234. 

30 The inner holding arm 210 is pivotally connected at 

the sleeve 232 to the walls 226 of the outer holding arm 
208 through a pen, or other similar fastening means. The 
inner holding arm 210 pivots from a raised (out-of-the- 
way) position to a lowered position, where the inner 
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holding arm 210 is stopped by a tang 237. Figure 12 
illustrates the inner holding arm 210 in both of these 
positions. Although not shown, a spring may be provided 
to bias the inner holding arm 210 to the raised and/or 
5 lowered position. Also, a locking device may be provided 
to retain the inner holding arm 210 in the raised and/or 
lowered position. 

With reference to Figure 13, a shaft 238 extends from 
the outer holding arm 208 at its proximate end 212 and 

10 terminates at a head plate 241. The shaft 238 vertically 
reciprocates within a bushing 240. The bushing 240 
includes a bore 242 and a lip 244. A helical spring 246 
surrounds the shaft 238. The spring 246 is disposed at 
least partially within the bore 242 of the bushing 240, 

15 between the lip 244 and the head plate 241. 

When the holder 207 is lowered, the shaft 238 
reciprocates within the bushing 240 and the spring 238 is 
compressed. This causes an upwards restoring force, in 
the opposite direction. 

20 To retain the holder 207 in a lowered position, a 

locking device 247 is provided. The locking device 247 
includes a warm-like locking arm 248 that extends 
alongside and in the same direction as each holder 207. 
The locking arm 248 includes a proximate end 250 and a 

25 distal end 252. Near the distal end 252, a moon-shaped 
cam 254 is provided. The cam 254 has a curved upper 
surface 256 and a flat lower surface 258. A curved 
projection 260 extends from the distal end 252 of the 
locking arm 248. Near the proximate end 250, the locking 

30 arm 248 is connected to the bushing 240 by a torsion or 
spring bar 261. The torsion bar 261 provides a restoring 
force on the locking arm 248 when the locking arm is moved 
in a manner to be described. Alternatively, the locking 
arm 248 may have a construction that eliminates the need 
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for a torsion bar 261, For example, the locking arm may 
be directly connected to the bushing 240 if the locking 
arm 248 is made of a resilient material. 

The vial loading mechanism 200 will now be described 
5 in use. The vial loading mechanism is designed to be used 
with two different, industry standard size vials — a 13 
mm size vial and a 20 mm size vial, but can be built to 
utilize other sizes as well. 

If the 13 mm size vial is to be used, the clinician 

10 must make sure that the inner holding arm 210 is in the 
lowered position. This can be done by pivoting the inner 
holding arm 210 with the help of projection 236. The vial 
85 is inverted and the neck of the vial 85 is snapped 
into, or frictionally engaged with, the holding portion 

15 234 of the inner holding arm 210. The clinician forces 
the holder 207 to be lowered so that the spike 118 pierces 
the membrane seal 120 of the vial 85. Because the spring 
244 provides an upward force on the holder 207 when 
compressed, the holder 207 must be retained or locked in 

20 the lowered or locked position. This is accomplished 
through the locking device 247. As the holder 207 is 
lowered, the lower part of one of the walls 226 contacts 
the cam 224 of the locking arm .248, causing the locking 
arm 248 and cam 254 to move out of the way. The holder 

25 207 is further lowered until the locking arm is allowed to 
move back to its original, locked position. In the locked 
position, the flat lower surface 258 of the cam 254 
retains the holder 207 in this position, regardless of the 
restoring force of the spring 244. 

30 The bedside device monitors whether the vial 85 is in 

the locked position by a vial-attachment sensor (not 
shown) . 

To remove the vial 85, the locking arm 248 is moved 
laterally with the projection 260 until the flat lower 
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surface 258 of the cam 254 no longer blocks or retains the 
holder 207. The restoring force in the spring 244 causes 
the holder 207 to rise to its original position where it 
is maintained in an unlocked position by the force of the 
5 spring 244, The vial 85 is then removed from the holding 
arm 210. 

In the event that a vial 85 or protective cap 126 
does not replace the unloaded vial, the system will 
disenable the cassette 77 in order to maintain aseptic 

10 conditions. 

If the 20 mm size vial 85 is used, the inner holding 
arm 210 must be located in the upward (out-of-the-way) 
position. This may be done by pivoting the arm 210 
upwardly using projection 256. This allows the larger- 

15 size vial 85 to fit within the arcuate holding portion 216 
of the holder 207 to be lowered onto the spike 118 in the 
same manner as that described above. 

The vial loading mechanism of the present invention 
provides an improved, safe, and easy way of loading, 

20 retaining, and unloading vials in a bedside delivery 
system. The vial loading mechanism inhibits clinicians 
from contacting the spikes 118 of the system and hurting 
themselves. 

25 Example u^er interface 

Figure 14 is a diagram illustrating an example user 
interface for an automated medication management system 
300 according to one embodiment of the invention. More 
specifically, figure 14 illustrates a specific interface 

30 implemented in conjunction with the bedside control and 
delivery units illustrated in figures 5A and 5B. As would 
be apparent to one of ordinary skill in the art after 
reading this description, automated medication management 
systems 300, including the bedside delivery and control 



WO 99/10029 



PCT/US98/16813 



41 

units, can be implemented with alternative user 
interfaces. The description of the user interface now 
described is provided by way of example only. 

The user interface according to the embodiment 
5 illustrated in figure 14 is comprised of two sections, a 
user operation and interface section 504 and a display 
section 508. Display section 508 includes indicator 
lights and displays to provide a clinician with 
information regarding medications being administered to a 

10 patient. Indicators 509A-509E provide the clinician with 
information as to which of a plurality of IV ports are 
currently being used to administer medication. In the 
embodiment illustrated, there are three IV ports as 
denominated by indicators 509B, 509C, and 509D, a luer 

15 port denominated by indicator 509E, and a primary port 
indicated by 509A. 

A rate indicator 511 provides a numerical display as 
to the rate at which medication is being administered to 
the patient. In a preferred embodiment, this is provided 

20 in units of ml/hr. Display 512 provides an indication of 
the volume of the medication which has yet to be 
administered to the patient. In a preferred embodiment, 
this display is provided in units of milliliters. 

In one embodiment, indicators 511, 512 are 

25 implemented using LED or LCD display providing numerals of 
sufficient size and intensity such that they are easily 
legible. In alternative embodiments, alternative display 
technologies are utilized to provide a legible display. 

Power indicator 510 informs a user whether the system 

30 is running off of battery or AC power and an alarm 
indicator 513 provides an indication as to whether an 
alarm condition is present. These indicators are backlit 
such that the characters are illuminated when the 
indicator is activated. Alternative indicator types can 
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be utilized as would be apparent to one skilled in the 
relevant art. 

User operation and interface portion 504 is comprised 
of a plurality of buttons and a display screen to function 
5 as the primary user interface for the system. A power 
button 519 is used to power the system on or to place the 
system in a stand-by mode, a keypad 514 is used to allow 
manual entry of data by a user. The keypad 514 
illustrated in figure 14 is a numeric keypad allowing only 

10 the entry of numeric data. In alternative embodiments, 
alphanumeric keys, function keys and other types of 
keypads can be provided to allow the entry of additional 
data. Additionally, a cursor control keypad 515 is 
provided to move a cursor on display screen 516. 

15 In the embodiment illustrated in Figure 14, display 

screen 516 is a computer display screen such as that 
commonly used in personal computers. Display screen 516 
can be used to provide information to the user and to 
allow the user to enter control information. In one 

20 embodiment, the automated medication management system 300 
is a Windows-based system. In this embodiment, display 
screen 516 is used to provide menu options or window 
screens to the user to allow the user to control the 
system as well as to provide information regarding the 

25 operation of the system, a cursor keypad 515 is provided 
to allow the operator to position a cursor on display 
screen 516 to enable selection. 

Additional buttons 520 are provided to allow 
additional control selections to be made by the operator. 

30 Buttons such as option button 520A, O.K. button 520B, 
cancel button 520C, run/hold button 520D and non-IV button 
520E and menu button 520F are used to select a pull-down 
menu 524, confirm a selection, cancel a selection or 
operation, pause or resume an operation or to allow an 
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operator to designate that a medication being administered 
is other than an I. V. -type medication. Indicators 517 are 
used to indicate which portions of display screen 516 
provide information with regard to particular I.V. ports. 
5 As stated above, alternative configurations can be 

provided for the user interface depending on the 
application and environment for the system. The 
embodiment illustrated in Figure 14 provides an example of 
a specific user interface in one embodiment of the system. 

10 After reading this description, it will become to a person 
skilled in the relevant art how to implement alternative 
user interfaces which allow control, operation and 
monitoring of the system. In a more generic embodiment, 
for example, the entire user interface can be implemented 

15 using a computer display screen in conjunction with a 
keyboard and/or a mouse. In this embodiment, all of the 
control and display operations are accomplished using 
conventional computer interface techniques. 

20 Example Architecture For A n Automated Medication Manage- 
ment System 300 

Figure 16 is a block diagram illustrating an example 
architecture for an implementation of automated medication 
management system 300. This example architecture is now 
25 described with reference to Figure 16. After reading this 
description, it will be apparent to a person skilled in 
the relevant art how to implement automated medication 
management system 300 using alternative architectures. 

The architecture illustrated in Figure 16 is 
30 comprised of five primary modules: system board 1801, 
programming panel 1802, power supply board 1803, status 
panel 1804, and fluid delivery module 1805. Additionally, 
the architecture illustrated in Figure 16 includes several 
auxiliary elements. 



WO 99/10029 



PCTAJS98/16813 



44 

System board 1801 is primarily responsible for the 
control and operation of automated medication management 
system 300. System board 1801 is a processor-based board 
controlled by CPU 1855. In one embodiment, system board 
5 1801 is an X86-based board capable of running the DOS or 
the Windows 3.1 or Windows 95 operating systems. In the 
illustrated architecture, RAM 1806 and program memory 1865 
are used to store data necessary for the operation of CPU 
1855. Instructions for controlling the operation of CPU 
10 1855 are stored in program memory 1865. RAM 1860 is used 
by CPU 1855 to store operating information. Additionally, 
battery-backed RAM 1850 is provided to store information 
that needs to be maintained between power cycles of the 
system. A real time clock 1890 is provided to maintain 
15 synchronization of CPU 1855. 

System board 1801 also includes a tilt sensor 1835 
and a temperature sensor 1840 to sense the operating 
environment of the system. These boards communicate with 
CPU 1855 via a sensor interface 1845. As would be 
20 apparent to one of ordinary skill in the art, additional 
sensors can be included to receive and provide data 
regarding the operating environment or numerous other 
parameters important to the operation of automated 
medication management system 300. In addition to the 
25 above-described components, system board 1801 includes a 
plurality of interfaces and controllers used in 
communication with the other modules, external 
peripherals, and other systems and devices. 

The interfaces include a power supply interface 1875, 
30 a status panel interface 1880, and IrDA interface 1885 
(infrared device interface), a fluid delivery module 
interface 1895, a printer interface 1870, a PCMCIA 
interface 1861, an external serial interface 1859, an 
auxiliary FDM (fluid delivery module) interface 1858, an 
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LCD controller 1857, a keypad controller 1854, and a bar 
code reader interface 1853. Each of these interfaces and 
controllers provide the communications necessary to 
interact with the devices and modules to which they are 
5 connected. Each of these interfaces and controllers are 
discussed below with reference to the modules and devices 
with which they interact. 

Programming panel 1802 is provided to allow an 
operator or user of the system to program or otherwise 

10 control the operation of the automated medication 
management system 300. a key pad 1821 allows the user to 
enter data or control the operation of automated 
medication management system 300. Key pad 1862 in one 
embodiment has a simple numeric key pad in combination 

15 with four arrow keys to provide cursor control. With a 
simple key pad such as this, a user can navigate his or 
her way around options displayed on a screen such as a 
CRT, and select those options to operate the system. More 
complex key pads including alphanumeric buttons and/or 

20 function keys can be utilized to provide additional levels 
of control. Key pad 1821 is interfaced to system board 
1801 by a key pad controller 1854. 

LCD display 1822 is utilized to provide a display to 
the user. Control information for operation of the system 

25 can be provided in the form of menus or other displays 
which can be used by the operator during normal operation 
of the system. LCD display 1822 interfaces with system 
board 1801 via LCD controller 1857. Although the 
embodiment illustrated in Figure 16 utilizes an LCD 

30 display, other types of displays can be utilized 
including, for example, a CRT type display. In addition 
to key pad 1821, input devices such as a mouse, joystick, 
or other data entry or control device can be utilized. 
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Power supply board 1803 is used to control and 
monitor the power provided to automated medication 
management system 300, Power supply board 1803 
communicates with system board 1801 via power supply 
5 interface 1875 and includes a power supply monitor 1831, 
an AC power supply and charger 1832, a battery 1833, and 
voltage regulators 1834. Power supply board 1803 receives 
its source of power from a main power inlet 1818 and 
provides various system voltages 1898 to operate automated 
10 medication management system 300. AC power supply and 
charger, in combination with voltage regulators 1834, 
receives AC power from main power inlet 1818 and provides 
the necessary AC and/or DC voltages required to operate 
the system as system voltages 1898. Additionally, AC 
15 power supply and charger 1832 provides a charging signal 
utilized to charge batteries 1833. Batteries 1833 provide 
an alternative source of power for automated medication 
management system 300 should the AC. power source become 
unavailable, substandard, or otherwise inadequate. Power 
20 supply monitor 1831 monitors the condition of the AC power 
supply and charger 1832, battery 1833, and voltage 
regulators 1834 to determine the condition and integrity 
of power sources and the power being provided to automated 
medication management system 300. Power supply monitor 
25 1831 utilizes this information to make decisions regarding 
the source of power for the system and to inform system 
board 1801 regarding the status of the power supply. 

Status panel 1804 is used to provide status and 
additional information to a user or operator of the 
30 system. Status panel 1804 interfaces with system board 
1801 via status panel interface 1880. Status panel 1804 
includes an LED display and audio controller 1841 and an 
IrDA transceiver 1843. LED display and audio controller 
1841 provides drivers for an LED display 1842 and a 
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speaker 1819. In this manner, audio and visual 
information can be provided to the user regarding the 
status and operation of the system. 

IrDA transceiver 1843 is used to communicate with an 
5 external device having an infrared communication 
transceiver. IrDA transceiver 1843 provides the necessary 
conversions between the infrared communications signal and 
electronic communications signal such that system board 
1801 can communicate with a device having an. infrared 

10 communication port. IrDA transceiver 1843 communicates 
with system board 1801 via IrDA interface 1885. 

Fluid delivery module 1805 is a module responsible 
for controlling the admixture and delivery process. Fluid 
delivery module 1805 communicates with system board 1801 

15 via fluid delivery module interface 1895. More 
specifically, an SMP interface 1845 is provided to return 
status information regarding the operation of fluid 
delivery module 1805. 

Printer 1817, which interfaces with system board 1801 

20 via printer interface 1870, is utilized to provide a hard 
copy printout of information relevant to the operation, 
maintenance and control of automated medication management 
system 300. 

A bar code reader 1812 is utilized to read 
25 information coded in the form of optical bar codes. The 
information from a scanned bar code is provided to system 
board 1801 via bar code interface 1853. Bar code reader 
1812 can be implemented using a hand-held bar code reading 
device which is easily positioned in proximity with the 
30 bar code to be scanned. Bar code reader 1812 can be hard 
wired or can have a wireless interface to bar code 
interface 1853. One form of bar code reader 1812 suitable 
for use with automated medication management system 300 is 
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the type of hand-held bar code reader often seen at the 
checkout line of many retail establishments. 

Auxiliary FDM port 1813 which interfaces with system 
board 1801 via auxiliary FDM interface 1858 is utilized to 
5 provide communications with one or more auxiliary fluid 
delivery modules. As such, system board 1801 can be 
utilized to provide control and operation of a plurality 
of fluid delivery modules. Serial port 1814 and network 
connection 1815 are utilized to provide communications 

10 interface with external entities. Serial port 1814 can be 
an RS-232 or other serial communications port and 
interfaces with system board 1801 via external serial 
interface 1859. Network connection 1815 typically 
operates at a higher data rate than serial port 1814, and 

15 is utilized to connect system board 1801 to a network. In 
the embodiment illustrated in Figure 16, the network 
connection is made by way of a PCMCIA interface 1861. a 
PCMCIA interface is desirable due to its small size and 
low power consumption features. However, as will be 

20 apparent to one of ordinary skill in the relevant art, the 
network connection need not be of the PCMCIA variety. 
Extended memory 1816, utilized to store data, is also 
interfaced with system board 1801 via PCMCIA interface 
1861. Various components of system board 1801 are 

25 connected via system ADC lines 1862. In one embodiment, 
system ADC lines 1862 are a conventional bus structure 
having address, data and control lines, as well as control 
logic necessary for the operation thereof. 

This architecture presented in Figure 16 is described 

30 to provide a detailed example of one possible 
implementation of an architecture for automated medication 
management system 300. After reading this description, it 
will be apparent to one of ordinary skill in the art how 
automated medication management system 300 can be 
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implemented using alternative architectures and that the 
implementation of an automated medication management 
system in accordance with the invention is not limited to 
the architecture depicted in Figure 16. Additionally, 
5 numerous features and components of an automated 
medication management system are described elsewhere in 
this document and are not illustrated as being implemented 
in the example architecture illustrated in Figure 16. 
However, it will likewise be apparent to one of ordinary 
10 skill in the art how these additional components and/or 
features can be implemented in conjunction with this or an 
alternative architecture. 

Automated Health Care Environment 
15 As discussed above, the automated medication 

management system 300, in accordance with one or more 
embodiments, can be integrated with a health care facility 
through a network or other communication means. Figure 17 
is a diagram illustrating an example implementation an 
20 automated health care facility 800 according to one 
embodiment of the invention. As will be apparent to one 
of ordinary skill in the art after reading this 
description, numerous alternative architectures can be 
used to implement the health care facility and provide the 
25 described functionality. 

The automated health care facility 800 in this 
embodiment includes a network 804 which is used to 
integrate the various components of the health care 
facility. Network 804 can be implemented using local-area 
30 or wide-area network technologies and can be a single 
network as illustrated in Figure 17, or can comprise a 
plurality of interconnected networks. Alternative tech- 
niques for interconnecting the elements of automated 
health care facility 800 can be utilized as well. 
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The health care facility illustrated in the example 
embodiment of Figure 17, includes one or more pharmacies 
803, one or more administration entities 808, one or more 
automated medication management systems 300, one or more 
5 nursing stations 816, one or more sentries 834 one or more 
data servers 820, and one or more data entry terminals 
824. Also included in the illustrated embodiment are one 
or more external interfaces 830, as well as one or more 
automated admixture and delivery units 812. 

10 As would be apparent to one of ordinary skill in the 

art after reading this description, additional facilities 
can be integrated with the network to provide additional 
functionality to suit the particular implementation of the 
health care system. Additionally, portions of the 

15 described facility which may not be needed for particular 
implementations can be omitted. Furthermore, alternative 
configurations can be implemented without departing from 
the spirit and scope of the invention. 

The manner in which patient and medication informa- 

20 tion are handled in the health care facility is now 
described according to several example embodiments. As 
described above, health care professionals in the course 
of treating a patient often prescribe medication to be 
administered to the patient. This information can be 

25 entered into the system using data entry terminals, such 
as data entry terminals 824. These can be portable (such 
as, for example, hand held, or otherwise transportable) 
data entry terminals or stationary data entry terminals 
located at convenient locations for the entry of data. 

30 Additionally, clinicians and other health care 
professionals can use these terminals to enter other 
information germane to the treatment of the patient and 
his or her stay at the facility. 
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Examples of the types of data which can be entered in 
the data entry terminals 824 include patient information, 
medication information, and other information. Patient 
information can include, for example, the patient's vital 
5 signs, the patient's condition, patient allergies, 
existing patient medications, as well as other information 
which may be useful in the diagnosis or treatment of the 
patient. This patient information is ultimately stored on 
a patient database. 

10 In a typical hospital or other health care 

environment, information pertaining to the patient's 
condition and the prescribed medications, dosage and 
dosing intervals are entered into the patient's chart. In 
one embodiment of the invention, this information is 

15 entered into a database containing patient information for 
one or more patients at the health care facility. This 
database is referred to in this document as a patient 
database. This database can include additional informa- 
tion about the patient such as other medications the 

20 patient may currently be taking, either intravenously, 
orally, or otherwise; allergies the patient may have; 
patient demographics, such as, for example, the patient's 
age, weight, sex, and other like information; or other 
relevant or pertinent information including other 

25 information from the patient's chart. All of the informa- 
tion normally found on the patient's chart may be stored 
in the patient database to create a "virtual chart" for 
the patient. This virtual chart can be linked by a 
communication interface to one or more entities or 

30 facilities such as a pharmacy and other facilities. In 
this manner, data from the chart can be accessed from 
multiple locations. 

The data entry terminal can be a portable data entry 
terminal that can be carried or otherwise transported by 
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a health care professional from patient to patient; or one 
which is stationary and located, for example at a central 
location or in the patient rooms. 

In one embodiment, such information can also be 
5 entered using data entry device 312 in automated 
medication management system 300. In this embodiment, the 
information may be stored in automated medication 
management system 300 (such as, for example in data 
storage 316) as well as shared with other entities or 

10 databases through the use of communication interface 320. 

Data entry terminals 824 can include a wired or 
wireless communication interface providing direct or 
networked connection to the one or more entities or 
facilities with which the terminal communicates. For 

15 example, a fixed data entry terminal 824 located in the 
patient's room or near the patient, can have a hard-wired 
or wireless connection to network 804 so that information 
can be transmitted from data entry terminal 824 to the 
appropriate database or data server 820 or to pharmacy 

20 803. The portable data entry terminal can include 
wireless or hard-wired communications as well. 

Additionally, in one embodiment the portable data 
entry terminal can store entered data in a local memory as 
the health care professional is performing his or her 

25 rounds. In this embodiment, the health care professional 
may carry the portable data entry terminal 824 with him or 
her while conducting the rounds. As each patient is seen, 
examined or diagnosed, information pertaining to that 
patient obtained during the visit can be entered using the 

30 terminal. Such information can include the various types 
of patient information described in this document as well 
as a diagnosis of the patient and a prescription to treat 
the diagnosis. 
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At the completion of the rounds, or at other periodic 
intervals, the data can be downloaded from the data entry 
terminal to appropriate elements in the health care 
facility. For example, in the environment of the health 
5 care facility illustrated in Figure 17, a prescription may 
be forwarded to pharmacy 803, patient information may be 
stored in patient database 836, and so on. This can be 
done by wireless communications or by interfacing the 
portable data entry terminal to a hard-wired connection 
10 such as, for example, an RS232 port or a network interface 
card. 

Additionally, the communications between data entry 
terminals 824 and other network elements or other health 
care facility entities can be continuous (e.g., via an 

15 open channel of communication) or frequent enough such 
that the health care professional interacts with these 
entities and elements in real time. In this manner the 
health care professional can receive feedback from these 
entities and elements as data is entered. For example, 

20 where a physician enters a prescription for a patient, the 
physician can receive real-time feedback regarding the 
propriety of administering the prescribed medication to 
the patient. As another example, where the physician 
enters a patient diagnosis and utilizes an analysis 

25 package to recommend treatments, the physician can receive 
real-time feedback. As illustrated by these two examples, 
in this embodiment, the physician can make on-the-spot 
decisions regarding therapies prescribed for the patient. 
In the embodiment illustrated in Figure 17, a patient 

30 database 836 is used to store the patient data information 
entered from patient data entry terminals 824. From the 
data regarding a patient, patient profiles can be created 
to provide a synopsis of pertinent information pertaining 
to the patient. Thus, the patient database can include 
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detailed information regarding each patient as well as 
patient profiles. 

In the embodiment illustrated in Figure 17 , a patient 
database 836 is illustrated as being accessed by a data 
5 server 820. In alternative embodiments, patient database 
836 can be located elsewhere within the architecture or 
distributed among a plurality of locations. 

A pharmaceutical database 805 is provided to store 
information relating to one or more of the medications 

10 dispensed by the pharmacy. This information can include 
drug IV template and other information such as drug 
interaction precautions, recommended doses, side effects, 
warnings and other information which may be relevant to a 
decision regarding whether to administer the prescribed 

15 medication. Pharmaceutical database 805 can also include 
a hospital formulary list indicating the medications 
available to that pharmacy or for the hospital to which 
the patient is admitted. 

Although illustrated as directly tied to pharmacy 

20 804, pharmaceutical database 805 can alternatively be 
located elsewhere within the architecture or accessed by 
a server, such as, for example, data server 820 or 
distributed among several entities. 

In one embodiment, sensors 840 can be used to monitor 

25 a patient's vital signs and condition and to provide 
telemetry regarding the sensed patient information to 
update patient database 836. Additionally, information 
from sensors 840 can be used to provide information 
directly to the nursing stations 816. Examples of sensors 

30 84 0 can include heart rate, blood pressure, body 
temperature, and other sensors to sense a patient's 
condition. Sensors 840 can be hard wired to the network 
or other device or can use a wireless communication inter- 
face. Sensors 840 are illustrated as being interfaced 
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directly to network 804. Alternatively, sensors 840 can 
be interfaced via one or more entities, such as, for 
example, data entry terminals 824. 

In one embodiment, when prescription information is 
5 entered into data entry terminal 824 (or via data entry 
device 312), the prescription is forwarded to the pharmacy 
804. The delivery can be fully automatic, that is, 
delivery happens without further user intervention, or a 
command may be required to actually forward the 

10 prescription to pharmacy 804. Pharmacy 804 can include 
display screens, printers, terminals or other devices to 
provide the prescription information to the pharmacist. 
Patient and other information can be provided to the 
Pharmacist as well. Upon receipt of this information, the 

15 pharmacist fills the prescription. 

Prescriptions sent to pharmacy 840 can also include 
an identification of the patient. According to one 
embodiment, patient database 836 is checked in conjunction 
with the prescription to determine whether the patient has 

20 any allergies, conditions, or other factors which may 
indicate that the prescribed medication is not ideally 
suited to that patient. This check can be used to help 
prevent the prescription and administration of medications 
to a patient where that patient has a condition which 

25 renders the medication unsuitable for that patient or 
where the patient has already been prescribe the same or 
another medication to treat the current condition. This 
check can be performed by comparing the prescription 
information with information stored in patient database 

30 836. A simple example of such a check would be to look 
into patient database 836 to determine whether the patient 
is allergic to the prescribed medicine. 

Additionally, the prescribed medication and informa- 
tion regarding the patient and his or her condition in 
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patient database 836 can be compared against pharma- 
ceutical database 805 to determine whether the patient has 
any conditions or there are other circumstances which 
would give reason to reexamine the decision to prescribe 
5 the identified medication. 

Such a check can be performed as the physician enters 
the prescription information into data entry terminals 
824 , and thereby provide real time feedback to the health 
care professional. At this point, the health care 

10 professional can decide whether to proceed with the 
original prescription, performing a preemptive override of 
future alarms if necessary, change the prescription, or 
perform further investigation, examination, tests, or 
studies to determine the appropriateness of the prescribed 

15 therapy. 

This check can also be performed by pharmacy 804, 
automated medication management system 300, or other 
entity having access to this information. In one embodi- 
ment a sentry 834 is provided specifically to perform this 

20 medication-error-prevention function. In this embodiment, 
sentry 834 is a dedicated device which examines one or 
more of patient information, patient profiles, prescrip- 
tion information, and pharmaceutical information to 
determine whether the prescribed medication, dosage, and 

25 dosing interval are appropriate. Again, this can be done 
in real-time to provide immediate feedback, or offline. 

Once a prescription is checked to determine whether 
it is appropriate a message can be generated and provided 
to various elements of the health care facility. For 

30 example, where real-time feedback is provided to the 
prescribing physician, a message may be sent indicating 
the prescription was entered and accepted; or that the 
system has determined the prescription to be inappropriate 
and the reasons why such a determination has been made, 
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and perhaps suggestions of alternative therapies to be 
prescribed. Such messages can assist the physician in 
making decisions regarding the treatment of patients. 

Administration 808 can utilize information obtained 
5 by a network 804 to enhance and further automate the 
administration functions performed by the health care 
facility. For example, administration 808 can use drug 
event information and patient information to update its 
billing records; maintain . and manage inventory; schedule 

10 the availability of operating rooms, hospital beds, 
diagnostic and/or treatment equipment; and schedule or 
manage the use of other health care facilities. 

Additionally, it may be desired to have pharmacy 804 
maintain its own inventory, especially for critically 

15 controlled substances. Thus, in one embodiment, certain 
inventories can be performed by administration 808 and 
others by pharmacy 804. 

Administration 808 can have its own dedicated 
databases 862, or can utilize databases interfaced to data 

20 server 820. Additionally, administration 808 can draw 
data from existing databases serving other network 
entities. 

Automated admixture and delivery systems 812 can 
retrieve information from and provide information to 

25 network 804. As described above, in one embodiment, 
automated admixture and delivery systems 812 can be 
relocated and interfaced to network 804 as needed for data 
transfers. For example, automated admixture and delivery 
systems 812 can be moved from one patient to the next to 

30 deliver medication. In one embodiment, an example 
implementation of an automated admixture and delivery 
system 812 can be an automated medication management 
system 300. 
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Data server 820 can be used to provide interface to 
one or more databases such as, for example, patient 
database 836. Other databases as needed or desired can be 
interfaced via data server 820 to network 804. 
5 Additionally, in an alternative configuration from that 
illustrated in Figure 17, databases such as pharmaceutical 
database 805 and administration database 862 can be 
accessed via data server 820. As will be apparent to one 
of ordinary skill in the art after reading this 
10 description, data server 820 and its associated database 
can use mirroring, shadowing, or other techniques to 
provide redundancy as a safeguard against lost or tainted 
data. 

Nursing stations 816 can be provided at various 

15 points throughout the health care facility to provide a 
location for nurses, clinicians, and other health care 
professional to enter data into network 804 or to retrieve 
'data from network 804. In one embodiment, nursing 
stations 816 are implemented using a PC or other small 

20 computer with a network interface. Alternatively, they 
can be implemented using a terminal with a keyboard, mouse 
and monitor. Data entry devices such as, for example, a 
bar code reader may be provided as well. a nursing 
station 816 implemented with data entry capabilities can 

2 5 be used as an alternative (or in addition to) data entry 
terminals 824 to enter patient and other information. 

Additionally, a printer may be provided at nursing 
stations 816 to provide hard copy printouts for use in the 
treatment of patients and the administration of the health 

30 care facility. Additionally, a printer at nursing 
stations 816 can be used to create and print bar code 
labels to be used for things such a patient identification 
and other identification tasks. Printed labels can be 
provided with a sticky back so that they can be affixed to 
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the patient's chart, or other items appropriate for 
identification . 

In one embodiment, nursing station 816 includes a 
port for interfacing to the portable data entry terminals. 
5 • In this embodiment, the health care professional 
interfaces the portable data entry terminal with the 
nursing station to download data to network 804. 

External interface 830 can be used to provide an 
interface for network 804 to the outside world. Such an 

10 interface can be used to contact suppliers for supply 
information and ordering, to provide information to health 
care professionals outside of the hospital , and for other 
communication interfaces. 

The automated health care facility can also include 

15 an analysis feature to assist the health care 
professional, such as the tending physician for example, 
in determining a suitable medication to prescribe for the 
patient based information such as patient information, 
medication information, and other information which may be 

20 relevant. In this aspect of the invention, an analysis 
package is provided which considers a diagnosis of the 
patient, patient information from the database as well as 
information pertaining to the medications available in a 
designated pharmacy to suggest to the physician which 

25 medications may be appropriate to administer to the 
patient, and at what dosage levels and intervals. The 
package may provide list of alternative medications which 
can be used to treat the diagnosed condition and may also 
recommend alternative treatments or therapies as well. 

30 According to this analysis package, the system 

accepts the diagnosis of the patient as entered by the 
physician and checks the pharmaceutical database to 
determine which medications available in the formulary may 
be appropriate to treat the diagnosed condition. In one 
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embodiment , the system may also recommend medications not 
in the hospital formulary. 

Medication information available in one or more 
databases, such as, for example IV template information 
5 described below, is used to suggest recommended dosage 
levels and intervals to the physician for the suggested 
medications. The prescription analysis feature may also 
use other patient information to assist in the decision 
making process, such as, for example, patient allergies, 

10 patient demographics, other patient medications, or other 
patient information provided in the patient database or 
entered by the physician. 

The analysis package may rule out certain medications 
or highlight other medications based on this additional 

15 patient information. The analysis package may also 
recommend specific dosage levels based on the patient 
information. According to another aspect of the analysis 
package, the system may prompt the physician to enter 
additional information to aid in the decision making 

20 process. For example, consider a scenario where the 
patient's weight is not available in the patient database 
and this information is desired to accurately determine 
the dosage level. The system may ask the physician to 
enter the patient's weight into the system. Ideally, 

25 however, all of the patient's key information is already 
entered into the system or otherwise available from a 
database. 

In one embodiment, the analysis package also provides 
the health care professional with additional information 
30 pertaining to the recommended medications. For example, 
the physician may request a list of side effects for a 
recommended medication. This information can be used to 
assist the physician in the decision-making process as 
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well as to allow the physician to pass this information on 
to the patient. 

This additional information, such as side effects and 
other information can also be provided to other 
5 professionals such as the health care professional 
administering the medication. In this manner, the 
administering clinician can inform the patient of likely 
side-effects at the time of administration. 

In one embodiment, such information can be provided 
10 to health care professionals at a terminal such as a data 
entry terminal 824 and can be protected based on clearance 
levels. 

Additionally, links may be provided to on-line 
references and documents or to references and documents 

15 available on the Internet, for example, to provide the 
health care professional with quick and easy access to 
available on-line resources. For example, CD-ROM or other 
electronic versions of the Physicians Desk Reference or 
other documents may be provided and linked for access via 

20 data entry terminals 824 or other terminals. 

Figure 17 provides a representative functional 
architecture for the health care facility. As would be 
apparent to one of ordinary skill in the relevant art 
after reading this description, the functionalities 

25 described herein can be distributed among entities in 
alternative architectures. 

Ex^mp3 T e Architecture For An Order Entry Tgrmjnfll 

Figure 18 is a diagram illustrating an example 
30 architecture for a data entry terminal 824 according to 
one embodiment of the invention. Data entry terminal 824 
in this embodiment includes a controller 1904, which 
controls the operation of the terminal. Controller 1904 
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may be implemented, for example as a microprocessor or 
other processor-based system. 

A display 1908 and appropriate display drivers (not 
illustrated) can be used to provide messages to the user. 
5 Display 1908 can be implemented using, for example, an LCD 
display, an active matrix display, a CRT or other display 
device. Other indicators, such as, for example, LED' s or 
other indicator lights can be used as well. 

A speech synthesizer 1912 can be provided to compose 
10 vocal messages to be provided to the user. Both the 
display and the vocal messages can be used to prompt the 
user for input, inform the user of medication alerts or 
provide other messages to the user. For a hand-held 
device, a smaller display, such as an LCD display may be 
15 desired. For a larger device, a partial or full size CRT 
screen will provide more area for display. 

In an embodiment where the physician enters a 
diagnosis and the system provides suggestions regarding 
possible medications to prescribe, information regarding 
20 those medications and links to other references, a larger 
screen may be more desirable, although not required. 

Keypad 1916 can be used to provide data entry to the 
user. Keypad can be numeric or alphanumeric and can in- 
clude function keys or other special keys. Alternatively 
25 a full keyboard and mouse or other pointing device can be 
provided. In a hand-held device, it is generally desir- 
able to use a smaller keyboard or even a keypad. For a 
stationary terminal a full keyboard provides additional 
flexibility. 

30 Databases 1920 are illustrated as a part of data 

entry terminal 824. As discussed above, patient and/or 
medication information can be stored locally. In 
alternative embodiments, databases 1920 are not required 
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and the data is retrieved by communications interface 
1924. 

Processing of information to perform prescription 
checks or prescription analysis can be performed locally, 
5 for example by controller 1904, or remotely by sentry 834 , 
pharmacy 803 or other processing element. 

Communications interface 1924 provides uni- or bi- 
directional communications with other entities. Interface 
1924 can be a serial or parallel interface and can be 
10 wired or wireless. Peripherals 1932 can be interfaced to 
the terminal as well, including printers, disk drives and 
other devices. 

A code reader 1928, such as for example, a bar code 
reader, magnetic code reader, or other reader may be 
15 interfaced as illustrated. Code reader can be integrated 
with the terminal or in a separate housing. 

The integrated embodiment is ideal for the hand-held 
implementation. In the integrated embodiment, the reader 
may be disposed in the housing of the terminal with a 
20 window or other "receiver" positioned, for example, at the 
top edge of the terminal or on the bottom side of the 
terminal. In this manner, the hand-held terminal can be 
held up to the bar code, or magnetic stripe or other code 
and read the code. No wires or separate housings are 
25 required. 

For an embodiment where the reader is separate, the 
reader may be hand-held and moved about freely such that 
the scanner can be positioned to read codes. The reader 
may be either wired or wireless. Either version, and 
30 particularly the wireless version, may have internal 
storage to allow storage of read data and downloading via 
batch transfers. 
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As would be apparent to one skilled in the art after 
reading this description, alternative architectures can be 
provided for implementing data entry terminals 824. 

5 Hardware Anfl Software Implementations 

The various devices, components, and entities 
described above and illustrated in block diagram form may 
be implemented using hardware, software or a combination 
thereof and may be implemented in a computer system or 

10 other processing system. In fact, in one embodiment, 
these elements are implemented using a computer system 
capable of carrying out the functionality described with 
respect thereto. An example computer system 702 is shown 
in Figure 19. The computer system 702 includes one or 

15 more processors, such as processor 704. The processor 704 
is connected to a communication bus 706. Various software 
embodiments are described in terms of this example 
computer system. After reading this description, it will 
become apparent to a person skilled in the relevant art 

20 how to implement the invention using other computer 
systems and/or computer architectures. 

Computer system 702 also includes a main memory 708, 
preferably random access memory (RAM) , and can also 
include a secondary memory 710. The secondary memory 710 

25 can include, for example, a hard disk drive 712 and/or a 
removable storage drive 714, representing a floppy disk 
drive, a magnetic tape drive, an optical disk drive, etc. 

The removable storage drive 714 reads from and/or writes 
to a removable storage medium 718 in a well known manner. 

30 Removable storage media 718, represents a floppy disk, 
magnetic tape, optical disk, etc. which is read by and 
written to by removable storage drive 714. As will be 
appreciated, the removable storage media 718 includes a 
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computer usable storage medium having stored therein 
computer software and/or data. 

In alternative embodiments, secondary memory 710 may 
include other similar means for allowing computer programs 
5 or other instructions to be loaded into computer system 
702. Such means can include, for example, a removable 
storage unit 722 and an interface 720. Examples of such 
can include a program cartridge and cartridge interface 
(such as that found in video game devices), a removable 

10 memory chip (such as an EPROM, or PROM) and associated 
socket, and other removable storage units 722 and 
interfaces 720 which allow software and data to be 
transferred from the removable storage unit 718 to 
computer system 702. 

15 Computer system 702 can also include a communications 

interface 724. Communications interface 724 allows 
software and data to be transferred between computer 
system 702 and external devices. Examples of communica- 
tions interface 724 can include a modem, a network 

20 interface (such as an Ethernet card), a communications 
port, a PCMCIA slot and card, etc. Software and data 
transferred via communications interface 724 are in the 
form of signals which can be electronic, electromagnetic, 
optical or other signals capable of being received by 

25 communications interface 724. These signals are provided 
to communications interface via a channel 728. This 
channel 728 carries signals and can be implemented using 
a wireless medium, wire or cable, fiber optics, or other 
communications medium. Some examples of a channel can 

30 include a phone line, a cellular phone link, an RF link, 
a network interface, and other communications channels. 

In this document, the terms "computer program medium" 
and "computer usable medium 77 are used to generally refer 
to media such as removable storage device 718, a hard disk 
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installed in hard disk drive 712, and signals on channel 
728, These computer program products are means for 
providing software to computer system 702. 

Computer programs (also called computer control 
5 logic) are stored in main memory and/or secondary memory 
710. Computer programs can also be received via communi- 
cations interface 724. Such computer programs, when 
executed, enable the computer system 702 to perform the 
features of the present invention as discussed herein. In 

10 particular, the computer programs, when executed, enable 
the processor 704 to perform the features of the present 
invention. Accordingly, such computer programs represent 
controllers of the computer system 702. 

In an embodiment where the elements are implemented 

15 using software, the software may be stored in a computer 
program product and loaded into computer system 702 using 
removable storage drive 714, hard drive 712 or communica- 
tions interface 724. The control logic (software), when 
executed by the processor 704, causes the processor 704 to 

20 perform the functions of the invention as described 
herein. 

In another embodiment, the elements are implemented 
primarily in hardware using, for example, hardware compo- 
nents such as application specific integrated circuits 
25 (ASICs) . Implementation of the hardware state machine so 
as to perform the functions described herein will be 
apparent to persons skilled in the relevant art(s). 

In yet another embodiment, elements are implemented 
using a combination of both hardware and software. 

30 

iv Template? 

In one embodiment, software is provided enabling the 
pharmacy to choose their formulary drugs and the 
respective drug delivery parameters from a comprehensive 
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list of alternatives. One or more of the drugs in the 
formulary will preferably have a list of parametric limits 
associated with it. For example an IV template can 
contain the following fields of information relative to 
5 the mixing and delivery of a medication: 





Sample Template Fields 


«h 4* V% ^9 


10 


Diluent Exceptions 


Diluents which are prohibited 
rrom oeing usea wiun une 
specified drug 




Additive Exceptions 


Additives which are added to 
tne iv solution source ana are 
prohibited from being used 
with the specified drug 


15 


Maximum Delivery Rate 


Maximum delivery rate set by 
the pharmacist for a specific 
drug 


Maximum Dilution 
Volume 


Maximum volume to be infused 
set by the pharmacist for a 
specific drug 


20 


Minimum Delivery Rate 


Minimum delivery rate for the 
corresponding drug 


Minimum Dilution 
Volume 


Minimum voiuiuc lu uc iinuacu 
for the corresponding drug 


25 


Nominal Delivery Rate 


Delivery rate recommended by 
the pharmacy for the 
corresponding drug 


Nominal Dilution 
Volume 


Recommended volume to be 
infused by the pharmacy for 
the corresponding drug 


30 


Nominal Reconstitution 
Volume 


Volume of diluent to be used 
in the reconstitution 




Stability Time 


Time which drug will remain 
stable after reconstituting 
and/or diluting 


35 


Drug Requiring 
Reconstitution 


Indicate whether drug is 
powdered or lyophilized 
requiring reconstitution 



WO 99/10029 



PCTAJS98/16813 



68 

The pharmacy can then set the IV Template parameters 
to preferred values. Once the parameters are set for the 
medications in the hospital pharmacy formulary, the data 
can be imported via, for example, wired or wireless 
5 communication, or the network, into each bedside device 
where it is resident for dose administration, or in the 
data entry terminals where it is resident for prescription 
entry. When the hospital formulary is changed from time 
to time, the pharmacy may add or delete items from the 

10 pharmaceutical database. 

As discussed above, automated medication management 
system 300 allows the clinician identify the drug and the 
diluent during setup via the bar code scanner or selection 
from a drop down menu or entry via other user interface. 

15 In one embodiment, the identified drug must match an item 
in the pharmaceutical database for the system to begin 
mixing and/or infusing. Once the match is made by the 
present invention, the recommended mixing and/or delivery 
parameters are displayed on the user interface for the 

20 clinician to review. The parameters can be changed by the 
clinician as long as the change conforms to the minimum 
and maximum recommendations set forth in the pharma- 
ceutical database. If the change does not conform, the 
clinician is notified that the parameters are out of 

25 range. In one embodiment , administration of the medica- 
tion will not be permitted to proceed unless a profes- 
sional with the proper level of authorization allows the 
out of range delivery. 

In the event that the IV solution source is 

30 prohibited according to the pharmaceutical database for an 
inappropriate diluent or incompatible additive, the clini- 
cian may be required to change the solution source 
container to an appropriate diluent with the proper addi- 
tive. After changing the solution source container, the 



WO 99/10029 



PCT/US98/16813 



69 

system automatically reprimes the fluid pathways with the 
new diluent prior to beginning the cycle. 

Instructions for Use 
5 In one embodiment, the general sequence of steps for 

the user to operate the automated medication management 
system for delivery of an IV drug, is as follows: 



10 


SECTION 


CONTENTS 




1. Instrument 
Preparation 


Turn power on and load cassette and 
set if IV delivery is desired 
through the device 


15 


2. Selecting the 
IV Source Solution 


Identify Patient ID and Clinician 
ID by bar code scan or keypad 
entry. Identify IV Source Solution 
by bar code scan or select from 
displayed list. Select the 
prescribed base solution additives 
from the displayed list and enter 
the volume for each with the keypad 


20 


3. Priming the 
Delivery Set 


Press Prime key to automatically 
prime the proximal tubing and 
cassette. Press and hold Prime key 
to prime the distal tubing 


A . Loading the 
Vial 


Insert the vial into the adapter 
and press the vial on to the vial 
spike until the vial retention 
latch clicks into place. (The 
device will acknowledge that the 
vial is loaded properly and prompt 
user) . The clinician is reminded to 
utilize aseptic techniques to avoid 
touch contamination of the vial 
spikes or luer port adapter. 


25 


5. Scheduling 
Primary Delivery 


Select the Primary Delivery key 
Enter the Rate and Volume To Be 
Delivered. Enter time for delivery 
to begin (If there is a scheduling 
conflict the user will be prompted 
to change the start time) 
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SECTION 


CONTENTS 


6. Scheduling a 
Vial Port 


Press a Vial Port Key. Scan the 
vial bar code or select the drug 
from the displayed list. The IV 
Template information in the 
Pharmacy preset will be displayed* 
Clinician may change the delivery 
rate, duration of delivery and 
total dilution volume within the 
Pharmacy boundary limits. If the 
scheduled delivery time exceeds the 
respective Drug Stability time, the 
clinician will be prompted to 
change the delivery time. If there 
is an incompatibility with the IV 
Source Solution or Additives, the 
Clinician will be prompted to 
change the IV Source Solution 
container. After changing, the 
device will automatically reprime 
fluid pathways with new IV Source 
Solution. 


Scheduling the 
Luer Port 


Press the Luer Port key. Scan the 
bar code or select the drug from 
the displayed list. The IV Template 
information in the Pharmacy preset 
will be displayed. Clinician may 
change the delivery rate, duration 
of delivery and total dilution 
volume within the Pharmacy boundary 
limits . 


Starting Admixture 
and Delivery 


After scheduling the ports, the 
clinician presses run and the fluid 
delivery cycle begins 



10 

This sequence is provided as an example only to 
illustrate the operation of one embodiment of the 
invention. After reading this description, it will become 
apparent to one of ordinary skill in the art how 
15 alternative embodiments may be operated using alternative 
procedures. 

Figure 20 provides an overview of an example 
automated medication management system 300 according to 
one embodiment. After powering automated medication 
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management system 300 on, if the system is connected to 
the network, the system checks the version of the software 
resident in the system with that available over the 
network. If the system's version does not match the 
5 version carried on the network, the system updates the 
version and operates off that new version. 

The clinician enters a password to enable the system 
to unlock the front panel and display a start-up screen. 
The front panel lock feature can be set up by the health- 

10 care facility in a preference-setting section within the 
software so that after a timeout period of no activity has 
expired, the instrument automatically goes into front 
panel lock. This provides security against unauthorized 
use of automated medication management system 300. The 

15 user may also enter into front panel lock on a 
predetermined command. 

After display of the startup screen, the clinician 
may press a number of different keypad buttons to access 
different routines. If any of the keypad buttons P, 1, 2, 

20 3 or L are pressed, the system checks whether a cassette 
is loaded. Should a cassette be loaded and be uncompro- 
mised, the system proceeds to the cassette priming 
procedure, illustrated in Figure 23. 

Figure 21 illustrates a Patient ID Routine according 

25 to one embodiment. This routine describes a sequence of 
events for identifying the patient to automated medication 
management system 300. Whether this feature is enabled can 
be determined by the health care facility. If the patient 
identification feature is not desired, the system exits 

30 this subroutine immediately. Should patient ID be 
desired, the system checks to see if the patient ID has 
already been entered. If it has not already been entered, 
it can now be entered via bar code, or it can be entered 
via keypad entry. The identification can be in the form 
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of the patient ID number or the patient's name or other 
code. This information can be used for accessing one or 
more databases to pull the patient profile information or 
other patient information. By accessing such data, 
5 automated medication management system 300 can perform 
medication error checking. 

Figure 22 illustrates a Clinician ID Routine accord- 
ing to one embodiment of the invention. The clinician ID 
routine is analogous to that performed for the patient ID 

10 as described above with reference to Figure 21. Clinician 
ID is performed according to facility preference. Should 
a health care facility prefer to track information based 
on a particular clinician's actions, the identification 
feature can be enabled. The system can accept a barcode 

15 or a keypad entry of the clinician's ID, name, PIN or 
other identifiers. 

Figure 23 illustrates a cassette loading and priming 
procedure according to one embodiment. After a clinician 
opens and closes both the inner and the outer door, the 

20 system determines whether a cassette 77 is in place. In 
one embodiment, should cassette 77 be present and have 
been used before, it will have been irreversibly 
compromised by operation of the two shut-off valves or by 
some other means. If the cassette is not compromised, 

25 then the clinician may proceed to the cassette priming 
sequence. If any of the P, 1, 2, 3 or L buttons are 
pressed on the keypad, the system checks to determine 
whether a cassette 77 is in place. If no cassette 77 is 
in place, automated medication management system 300 

30 prompts the clinician to install the cassette and performs 
a check for a compromised cassette. 

Once cassette 77 is loaded, the system prompts the 
clinician to identify the primary solutions for 
administration by either bar code scan of the solution 
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container label, or to enter in all the components of that 
solution via a set of lists that are supplied in the user 
interface. Should the patient profile or other patient 
information be available, the system checks the solution 
5 being administered versus what was actually prescribed. 
Should the system find no errors, it initiates "automatic 
priming. " The user is prompted to press "OK, " and then 
the system automatically primes the cassette from the bag 
all the way to the distal exit port. At this point, the 

10 system then initiates a manual priming sequence, which is 
a user-activated and controlled sequence. The system 
prompts the user to press and hold a prime button until 
the user sees fluid coming out the distal end of the tube, 
at which point the user releases the button. 

15 Once the cassette is properly primed, the user can 

press P, 1, 2, 3, or L. Automated medication management 
system 300 begins the programming sequence the selected 
port. For example, in figure 31, the £ button has been 
pressed. This indicates that the primary solution 

20 delivery, or the primary port, is about to be programmed. 
When the primary button is pressed, programming of that 
port is initiated. All parameters that have been 
previously entered appear for modification or verification 
and approval. Empty data fields such as rate of delivery 

25 or the volume to be infused (VTBI) can be entered. 
Required data fields, as determined by the hospital, must 
be completed. Upon entry of the necessary data, the user 
is prompted to approve the entries by pressing OK. When 
"OK" is pressed, the port is programmed and the programmed 

30 operation is initiated. 

Figures 32A and 32B are flow diagrams illustrating 
programming of ports 1, 2, and 3 according to one 
embodiment. Ports 1,2, and 3, are the vial attachment 
ports. When a port button is pressed, the instrument 
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prompts the user to identify the drug by either scanning 
the bar code of the drug vial, or selecting the drug from 
the drugs that are listed in the current Patient Profile 
(networked), or by use of a larger drop down list. If the 
5 drug is selected from the comprehensive list and not from 
the patient profile, the drug name is again displayed for 
verification. This action forces a review of the planned 
action for correctness of drug and patient, and helps to 
reduce medication errors. 

10 If the drug was identified via a bar code scan, the 

bar-code-scanned drug can be checked against data such as 
the patient profile. If the drug is present on the patient 
profile list the user is allowed to proceed. If not 
present, the user is notified of the situation and asked 

15 to review their planned action for correctness of drug and 
patient. The user is also asked if they still wish to 
proceed. 

Once the drug has been identified, and verified 
against the patient profile, and/or accepted by the user, 
20 the instrument references the IV templates. Information 
in the IV templates includes the final dilution volume, 
the diluent the drug will be put into, solutions this drug 
is compatible or incompatible with, suggested rates of 
delivery, reconstitution volumes, and other data elements 

25 important to the safe delivery of this drug. The user 
can confirm those settings or make modifications to fields 
where permitted. Once this programming is complete, the 
instrument checks the drug to primary solution 
compatibility. If the drug and solution are compatible, 

30 all the programming is done and the instrument prompts the 
user to attach the drug vial to the port, this is Vial 
Attachment Routine, illustrated in Figure 24. 

The Vial Attachment Routine Flowchart highlights two 
levels of sensing on the vial attachment mechanism. The 
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ability to sense whether the vial loading mechanism is up 
or down, and the ability to detect whether the vial 
attachment locking mechanism is locked or unlocked. These 
sensing mechanisms enable the instrument to monitor ports 
5 that are being manipulated to notify the user of the 
appropriateness of their actions. If the vial lock 
mechanism was moved from the locked to the unlocked 
position on an incorrect port, the instrument warns the 
user of the consequences of proceeding and the user is 

10 able to recover from that situation. 

Once the vial has been correctly attached, the user 
is instructed to schedule the delivery of this medication 
as illustrated on charts 24 and 25. The ability to 
schedule medication for delivery in advance is a key 

15 feature of the device. In one embodiment, the delivery 
can be scheduled as much as 24 hours in advance. 

A drug to diluent incompatibility process, 
illustrated in figure 33, demonstrates a process the 
instrument and user go through if it is determined that 

20 the drug and the primary solution (diluent) are 
incompatible. In this situation, if the solution is 
incompatible with the drug, the instrument first looks at 
port L to see whether it is available for use. If port L 
is not already programmed for use, the instrument suggests 

25 a different solution source to be attached to that port 
for use with this drug when it is time to deliver that 
drug. If the Luer port is active and in use, the system 
suggests that the user schedule the incompatible drug to 
be delivered at some later time. 

30 Figure 34 generally outlines a network routine and 

checking of the Patient Profile according to one 
embodiment. The Luer port programming Figures 35A, 35B 
and 35C are a flow chart illustrating a luer port 
programming routine according to one embodiment of the 
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invention. Flow diagram 35A describes the instrument 
operation when the L button is pressed on the keypad. 
This is a similar program to the Vial Port programming 
except for one difference: There is no reconstitution or 
5 dilution done on the Luer port in this embodiment. The 
Luer port is for use with a pharmacy-prepared admixture 
that may come in a mini-bag , a syringe or a larger volume 
container. The instrument would prompt the user to 
identify the drug by one of the three means mentioned 

10 earlier; bar code scanning the label, by pulling the drug 
name from the Patient Profile List, or going to the larger 
comprehensive list. The instrument performs the check in 
the case of the bar code scanned drug or a drug selected 
from the larger list to make sure that it was the drug for 

15 this patient. The drug is scheduled for delivery in a 
similar fashion as the vial ports. 

Whether a vial port or a luer port, after each drug 
is delivered, the instrument preferably thoroughly rinses 
the cassette fluid paths, spikes, and in some cases the 

20 vials themselves to adequately clear any drug residual 
that could cause future compatibility problems. In the 
case of an incompatibility between a drug and solution, 
the instrument also rinses any incompatible solutions 
from the cassette prior to beginning the mixing of the 

25 drug with the new compatible solution* 

The flowcharts illustrated in figures 25-28 are 
related to the medications that are delivered outside of 
the automated medication management system unit. These 
could be oral, topical, eye drops, eardrops, suppositories 

30 lotions, and other IV s that are not delivered through 
automated medication management system 300 in one 
embodiment. Once the Other Meds button is pressed, the 
instrument performs the drug identification routine, 
Patient Profile, and other operations to check for 
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administration of medication. The same checks for 
correctness of information can occur. Because automated 
medication management system 300 in this embodiment does 
not physically prepare these doses for delivery, automated 
5 medication management system 300 completes pre- 
administration verifications and checks and then prompts 
the user to administer the dose. The instrument then 
prompts the user to enter the actual dosage delivered, the 
time of delivery, and any other information pertinent to 

10 the delivery which may be useful in a data record. The 
user may also enter a notation from a predefined list of 
possible notes. In the case of a non-automated medication 
management system 300 administered IV, automated 
medication management system 300 can establish a record 

15 for that particular medication as well. 

At a later time the user can complete these records 
by entry into one of the instruments menu selections. In 
this manner a record can be created for all meds delivered 
via automated medication management system 300 or external 

20 to the automated medication management system 300. The 
instrument can transmit that record to the various 
information systems within the health care facility, 
including, for example, the pharmacy; the admissions, 
discharges and transfers database, also known as the ADT; 

25 the billing information system; or other entity. The 
capability of creating an electronic Medication 
Administration Record (MAR) and other useful reports is 
another key capability. The instrument acts as a data 
collection point successfully acquiring all the 

30 information, at the patient's bedside, necessary to create 
those reports. 

Figure 29 is a flowchart illustrating a process 
relating to a door open request. Sensors exist on each of 
the two fluid delivery module doors, the outer and the 
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inner door. If the outer door is opened, the instrument 
displays a message to the clinician of the consequences of 
proceeding. If the user does not want to continue opening 
the door, they could close the outer door and continue 
5 normal operations. If they do continue and open the inner 
door the cassette may be compromised and rendered 
unusable. As discussed previously, this is a safety 
feature of the device. When a new cassette is loaded, the 
instrument senses when the doors are closed, test to 

10 verify proper closure, and check if the cassette has been 
previously compromised. 

Figure 30 is a flowchart describing the operation of 
the Hold/Run button according to one embodiment of the 
invention. The Hold button is typically a timed function 

15 enabling the instrument to be put on hold, stop all fluid 
delivery operations, at any time during its operation, 
subject to a typical five minute limitation before it will 
alarm that the instrument has been on hold too long. The 
Hold button can be used to silence an alarm condition. By 

20 pressing Hold the instrument is placed into a standby mode 
and the user has a period of time (five minutes in one 
embodiment) to fix the alarm condition. If the problem is 
unresolved, the instrument resumes the alarm indicating 
the hold period has expired. This is a safety feature to 

25 ensure that solutions continue to move to the patient and 
alarms are resolved quickly. 

Another feature of the system related to the Hold 
button is the operation of the Standby button. If the 
instrument were powered down, there may be no visibility 

30 as to whether the cassette doors were opened or closed or 
vial attachment mechanisms were actuated. By 
incorporating a standby command, along with the power 
command, on the keypad, the user is offered a choice of 
the condition. The default is standby for the instrument, 
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but the user can use the cursor to move down to a power 
down command and press "OK." If the power down command is 
chosen, the instrument informs the user of the 
consequences, such as, for example, loss of the cassette, 
5 loss of patient information or loss of the network 
connection. Upon power up, parameters may need to be re- 
set, including for example patient ID, clinician ID, and 
so on. Standby mode maintains all the sensors on the 
doors and all the vial attachment mechanisms to notify 

10 users if there were any tampering going on the system 
would provide warnings and alarms to maintain the system' s 
integrity. The patient's ID is maintained in the standby 
mode and upon recovery needs to be verified. If there are 
any drugs previously scheduled on this instrument, the 

15 instrument examines the schedule, the current time, and 
asks the user to help resolve any issues by asking them to 
either reschedule drugs, to confirm drug deliveries, etc. 

In this document, the term database is generally used 
to refer to one or more data records or a collection of 

20 data regarding various types of information or data. This 
reference, along with any references to specific databases 
described herein are not intended to require a particular 
structure or organization of physical or logical 
databases. As would be apparent to one of ordinary skill 

25 in the art after reading this document, varying physical 
or logical data groupings can be provided in one or more 
locations or on one or more devices to implement the 
described databases. 

While the embodiments and applications of this 

30 invention have been shown and described, and while the 
best mode contemplated at the present time by the 
inventors has been described, it should be apparent to 
those skilled in the art that many more modifications are 
possible, without departing from the inventive concepts 
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therein. Both product and process claims have been 
included and in the process claims it is understood that 
the sequence of some of the claims can vary and still be 
within the scope of this invention. The invention 
5 therefore can be expanded, and is not to be restricted 
except as defined in the appended claims and reasonable 
equivalence departing therefrom. 
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Claims 

1. An automated medication infusion device, 
comprising: 

means for administration of an IV medication to a 
5 patient; 

a data entry device for entering an identification of 
said patient and an identification of medication to be 
administered to said patient; 

means for checking said prescribed medication against 
10 one or more databases to determine whether it is appro- 
priate to administer said prescribed medication to said 
patient; and 

means for alerting a clinician when it is not 
appropriate to administer said prescribed medication to 
15 said patient. 

2. The device according to claim 1, wherein said 
data entry device comprises at least one of the group of 
a bar code scanner, a keypad, a magnetic card reader, and 

20 a touch-screen display. 

3. The device according to claim 2, wherein said 
data entry device further comprises means for entering an 
identification of a health-care provider overseeing the 

25 administration of said medication to be administered to 
said patient. 

4. The device according to claim 1, wherein said 
means for checking said prescribed medication against one 

30 or more databases comprises means for determining whether 
any patient information in a patient database indicates a 
conflict with said prescribed medication. 
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5. The device according to claim 4, wherein said 
patient information in a patient database comprises at 
least one of the group of patient allergies medication, 
patient conditions, and other medication being given to 

5 the patient. 

6. The device according to claim 1, wherein said 
means for checking said prescribed medication against one 
or more databases comprises means for comparing prescrip- 

10 tion parameters against parametric limits for said 
medication. 

7. The device according to claim 6, wherein said 
prescription parameters comprise at least one of the group 

15 of dose, dosing interval, reconstitution level, diluent, 
and dilution amount. 

8. The device according to claim 4, wherein said 
means for checking said prescribed medication against one 

20 or more databases further comprises means for determining 
whether prescription parameters for said prescribed 
medication are within an acceptable range for a condition 
of said patient. 

25 9. The device according to claim 1, wherein said 

means for alerting comprises at least one of the group of 
an audible alarm or and visual alert. 

10. The device according to claim 9, wherein said 
30 visual alert comprises at least one of the group of a 
warning indicator and a screen display. 
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11. The device according to claim 1, further 
comprising display means for providing visual information 
to said clinician. 

5 12. The device according to claim 11, wherein said 

display means comprises at least one of the group of a CRT 
screen, an LCD screen, and indicator lights. 

13. The device according to claim 1, wherein said 
10 data entry device further comprises means for entering an 

identification of said clinician. 

14. The device according to claim 13, wherein said 
data entry device further comprises means for entering a 

15 password identification of said clinician. 

15. The device according to claim 1, wherein said 
data entry device comprises at least one of the group of 
a bar code scanner, a keyboard, a keypad, a touch-screen 

20 display and a card reader. 

16. The device according to claim 1, further 
comprising means for inhibiting the infusion of said 
medication when it is determined that it is not 

25 appropriate to administer said prescribed medication to 
said patient. 

17. The device according to claim 15, further 
comprising means for overriding said means for inhibiting 

30 the infusion of said medication. 

18. The device according to claim 16, wherein said 
means for overriding comprises means for determining an 
access level of said clinician and selectively allowing 
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said clinician to override said means for inhibiting the 
infusion of said medication based on said access level of 
said clinician. 

5 19. The device according to claim 1, further 

comprising a communications interface. 

20. The device according to claim 1, wherein said 
means for administering medication to a patient comprises 

10 means for reconstituting and/or diluting said medication 
to be administered to said patient. 

21. The device according to claim 20, wherein said 
means for reconstituting and/or diluting said medication 

15 to be administered to said patient comprises a disposable 
cassette. 

22. The device according to claim 1, further 
comprising means for ambulating said device. 

20 

23. The device according to claim 1, further 
comprising means for maintaining a record of medications 
administered to one or more patients. 

25 24. The device according to claim 23, further 

comprising means for updating an inventory of medications 
based on said record of medications administered to one or 
more patients. 

30 25. The device according to claim 23, further 

comprising means for updating an accounting record for 
said patient based on said record of medications 
administered to said patient. 
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26. An automated medication infusion device, 
comprising: 

means for receiving prescription information, said 
prescription information comprising information pertaining 
5 to a medication prescribed for a patient; 

means for checking said prescribed medication against 
one or more databases to determine whether it is 
appropriate to administer said prescribed medication to 
said patient; and 
10 means for alerting a clinician when it is not 

appropriate to administer said prescribed medication to 
said patient. 

27. The device according to claim 26, wherein said 
15 means for checking said prescribed medication comprises 

means for checking information in a patient database to 
determine whether said patient is allergic to said 
prescribed medication. 

20 28. The device according to claim 26, wherein said 

means for checking said prescribed medication against 
information in a patient database comprises means for 
checking information in a patient database to determine 
whether said patient suffers from a condition which would 

25 be aggravated by said prescribed medication. 

29. The device according to claim 26, wherein said 
means for checking said prescribed medication against 
information in a patient database comprises means for 
30 checking information in a patient database to determine 
whether said patient is presently being administered 
another medication which is incompatible with said 
prescribed medication. 
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30. The device according to claim 26, wherein said 
means for checking said prescribed medication against one 
or more databases comprises means for comparing a 
prescribed dosage level of said prescribed medication 

5 against a stored recommended dosage level for said 
prescribed medication. 

31. The device according to claim 26, wherein said 
means for checking said prescribed medication against one 

10 or more databases comprises means for comparing a 
prescribed dosing interval of said prescribed medication 
against a stored recommended dosing interval for said 
prescribed medication. 

15 32. The device according to claim 26, wherein said 

means for checking said prescribed medication against one 
or more databases comprises means for comparing a 
prescribed dilution amount of said prescribed medication 
against a stored recommended dilution amount for said 

20 prescribed medication. 

33. The device according to claim 29, wherein said 
means for checking said prescribed medication against one 
or more databases further comprises means for determining 

25 whether prescription parameters for said prescribed 
medication are within an acceptable range for a condition 
of said patient. 

34. The device according to claim 2 6, further 
30 comprising a data entry device for entering an 

identification of said patient and an identification of 
medication to be administered to said patient. 
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35. The device according to claim 34, wherein said 
data entry device comprises at least one of the group of 
a bar code scanner, a keypad, a magnetic card reader, and 
a touch-screen display. 

5 

36. The device according to claim 34, wherein said 
data entry device further comprises means for entering an 
identification of a health-care provider overseeing the 
administration of said medication to be administered to 

10 said patient. 

37. The device according to claim 26, wherein said 
means for alerting comprises at least one of the group of 
an audible alarm or and visual alert. 

15 

38. The device according to claim 37, wherein said 
visual alert comprises at least one of the group of a 
warning indicator and a screen display. 

20 39. The device according to claim 26, further 

comprising display means for providing visual information 
to said clinician. 

40. The device according to claim 39, wherein said 
25 display means comprises at least one of the group of a CRT 

screen, an LCD screen, and indicator lights. 

41. The device according to claim 26, wherein said 
data entry device further comprises means for entering an 

30 identification of said clinician. 

42. The device according to claim 41, wherein said 
data entry device further comprises means for entering a 
password identification of said clinician. 
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43. The device according to claim 26, wherein said 
data entry device comprises at least one of the group of 
a bar code scanner, a keyboard, a keypad, a touch-screen 
display and a card reader. 

5 

44. The device according to claim 26, further 
comprising means for inhibiting the infusion of said 
medication when it is determined that it is not 
appropriate to administer said prescribed medication to 

10 said patient. 

45. The device according to claim 43, further 
comprising means for overriding said means for inhibiting 
the infusion of said medication. 

15 

46. The device according to claim 44, wherein said 
means for overriding comprises means for determining an 
access level of said clinician and selectively allowing 
said clinician to override said means for inhibiting the 

20 infusion of said medication based on said access level of 
said clinician. 

47. The device according to claim 26, further 
comprising a communications interface. 

25 

48. The device according to claim 26, wherein said 
means for administering medication to a patient comprises 
means for reconstituting and/or diluting said medication 
to be administered to said patient. 

30 

49. The device according to claim 48, wherein said 
means for reconstituting and/or diluting said medication 
to be administered to said patient comprises a disposable 
cassette. 
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50. The device according to claim 1, further 
comprising means for ambulating said device, 

5 51. The device according to claim 1, further 

comprising means for maintaining a record of medications 
administered to one or more patients. 

52. The device according to claim 51, further 
10 comprising means for updating an inventory of medications 

based on said record of medications administered to one or 
more patients. 

53. The device according to claim 51, further 
15 comprising means for updating an accounting record for 

said patient based on said record of medications 
administered to said patient. 

54. A computer-based method for automated delivery 
20 of a prescribed medication to a patient, comprising the 

steps of: 

receiving a prescription indicating the medication 
prescribed for a patient; 

electronically checking said prescribed medication 
25 against one or more databases to determine whether it is 
appropriate to administer said prescribed medication to 
said patient; and 

automatically alerting a clinician when it is 
determined in said step of electronically checking that it 
30 is not appropriate to administer said prescribed 
medication to said patient. 

55. The method according to claim 54, wherein said 
step of electronically checking said prescribed medication 
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comprises a step of checking information in a patient 
database to determine whether said patient is allergic to 
said prescribed medication. 

5 56. The method according to claim 54 , wherein said 

step of checking said prescribed medication against 
information in a patient database comprises step of 
checking information in a patient database to determine 
whether said patient suffers from a condition which would 
10 be aggravated by said prescribed medication. 

57. The method according to claim 54, wherein said 
step of checking said prescribed medication against 
information in a patient database comprises a step of 
15 checking information in a patient database to determine 
whether said patient is presently being administered 
another medication which is incompatible with said 
prescribed medication. 

20 58. The method according to claim 54 , wherein said 

step of checking said prescribed medication against one or 
more databases comprises a step of comparing a prescribed 
dosage level of said prescribed medication against a 
stored recommended dosage level for said prescribed 

25 medication. 

59. The method according to claim 54, wherein said 
step of checking said prescribed medication against one or 
more databases comprises a step of comparing a prescribed 
30 dosing interval of said prescribed medication against a 
stored recommended dosing interval for said prescribed 
medication. 
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60. The method according to claim 54, wherein said 
step of checking said prescribed medication against one or 
more databases comprises a step of comparing a prescribed 
dilution amount of said prescribed medication against a 

5 stored recommended dilution amount for said prescribed 
medication. 

61. The method according to claim 57, wherein said 
step of checking said prescribed medication against one or 

10 more databases comprises a step of determining whether 
prescription parameters for said prescribed medication are 
within an acceptable range for a condition of said 
patient . 

15 62. The method according to claim 54, wherein said 

step of alerting comprises a step of sounding an audible 
alarm. 

63. The method according to claim 54, wherein said 
20 step of alerting comprises a step of providing a visual 

alert. 

64. The method according to claim 54, further 
comprising step of inhibiting the infusion of said 

25 medication when it is determined that it is not 
appropriate to administer said prescribed medication to 
said patient. 

65. The method according to claim 64, further 
30 comprising a step of determining an access level of a 

clinician and selectively allowing said clinician to 
override said step of inhibiting the infusion of said 
medication based on said access level of said clinician. 
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66. The method according to claim 54, wherein said 
step of administering medication to a patient comprises 
step of reconstituting and/or diluting said medication to 
be administered to said patient • 

5 

67. The method according to claim 54, further 
comprising step of maintaining a record of medications 
administered to one or more patients. 

10 68. The method according to claim 67, further 

comprising a step of updating an inventory of medications 
based on said record of medications administered to one or 
more patients. 

15 69. The method according to claim 67, further 

comprising a step of updating an accounting record for 
said patient based on said record of medications 
administered to said patient. 



WO 99/10029 



PCT7US98/16813 



07/50 




SUBSTITUTE SHEET (RULE 26) 



WO 99/10029 



PCT/US98/16813 



02/50 




Fig. 2 

PRIOR ART 



DATA ENTRY 
DEVICE 
312 



300 




CONTROL AND 
MANAGEMENT 
304 





88 




77 




PREPARATION & 


DELIVERY 






308 







DATA 
STORAGE 
316 



COMMUNICATIONS 
INTERFACE 
320 



Fig. 3 



SUBSTITUTE SHEET (RULE 26) 



WO 99/10029 



PCT/US98/16813 



03/50 



EXAMINE PATIENT 






PRESCRIBE MEDICATION ' 






ENTER PA' 


riENT DATA - 







-404 



RECEIVE MEDICATION . 
FOR PATIENT 






PREPARE MEDICATION 






ADMINISTER MEDICATION 






UPDATE DATA BASES 



'412 



-4W 



Fig. 4 




SUBSTITUTE SHEET (RULE 26) 



WO 99/1 0029 



PCT/US98/16813 



04/50 




Fig. 5A 



SUBSTITUTE SHEET (RULE 26) 



WO 99/10029 



PCT/US98/16813 



05/50 




Fig. 7 



SUBSTITUTE SHEET (RULE 26) 



WO 99/10029 PCT/US98/16813 



06/50 



Cz> 



CD- 



r\ 



<£ 
CO 
CO 

o 

cz> 



OR 




o 


i — 


SCANNE 


THE Si 


CO 

o 


O 
1 — 




o 
ce 


PATH 


ENTE 



r 



UJ 

O. CO 



Lu 

B 

CO 



o 




=Z> 




oc: 






2 




UJ 


o 










>- 


CO 
UJ 


NTR 


CZt 


UJ 

GO 


O 


CJ> 




BAR 


UJ 
ZC 


& 


-ZL 




ZZL 


CZ> 


O 


UJ 


K— 


L-t- 


C_) 




UJ 




UJ 


UJ 

Q 


CO 


CO 


UJ 

I 


cz> 




ZZ> 




C£ 




o 





UJ ^ 



0£ 

o 



zs en 
o o 

uZ 5 



CD 



5 ^ 



o o 

f= I — ccr 

O ^ ' 

uj zc 

— i i— 
uj o 

co ct: 

, o 



g CO 

§ g 
Q 5 



uj 

1 



ZC 

cz> m 



co 
o 



CD 









1 — 




UJ 






oc 

Q_ 


PA 




UJ 




zc 




i — 


O 


o 




>— 






zs 


zs 


C£ 




O 




u- 


zc 


ZZ 


UJ 




CO 




zz> 


^ 


<c 




CJ 






O 


CZ> 


CZ> 
UJ 












ZZ> 










ZC 


o 


1 — 


o 


CO 


IN J 


o 


o 

UJ 


1 — 


zc 




o 





CO 








O 






CD 


g 






<c 


CD 




UJ 


o 


zs 


UJ 




Q 


o 


cn 


UJ 


o 


en. 


C3 
UJ 


UJ 

> 


ce 


— 1 


UJ 


UJ 


03 


>- 


I 


en 




ZE 




UJ 




CO 




u_ 

O 




21 


o 


O 


ZZ) 




ct: 


UJ 


o 






O- 


UJ 


zs 


zc 


o 

















CO 



s s 

■<: co 

CO UJ 



C5- 



o 

l^j 2 

cz> ct: 

3 £ 

O 

CD o 

Si 



co 

co ^ 

§ 1 

S 3 

cz> co z 

" o y 

^ 0£ 

o o <c 

UJ o 

ZC UJ 

o o- 

CO 

CO z 

o o 

cc p o: 

o S o 

C_> U- 

<2 o 



2 = 
zc 



o 

O ^ 

z or 

II 



3. 



o 

CO 

UJ 

Q g 

UJ 

en 

o g 

ZZJ 

ZZ) O 
C£ O 

CO 

ct: 

CZJ 
UJ 

o 



O 



CO ZC 

6; I 

O _J 



UJ oc 

S 3 
5 < 
°° 5 

UJ 

CO Q£ 

2 ° 
^ o: u >. 

w < s 

~ o 

UJ 



s 



o 



SUBSTITUTE SHEET (RULE 26) 



WO 99/10029 



PCT/US98/16813 




SUBSTITUTE SHEET (RULE 26) 



WO 99/10029 



PCT/US98/16813 



08/50 




DISPLAY 
1908 



KEYPAD 
1916 



SPEECH SYNTHESIZER 
1912 



CONTROLLER 
1904 




DATA BASES 
1920 



COMMUNICATIONS 
INTERFACE 
1924 



Fig. 18 



SUBSTITUTE SHEET (RULE 26) 



WO 99/10029 



PCT/US98/16813 



09/50 




SUBSTITUTE SHEET (RULE 26) 



WO 99/10029 



PCT/US98/16813 



10/50 




SUBSTITUTE SHEET (RULE 26) 



WO 99/10029 



PCT/US98/16813 



11/50 




SUBSTITUTE SHEET (RULE 26) 



WO 99/10029 



PCT/US98/16813 



12/50 




SUBSTITUTE SHEET (RULE 26) 



WO 99/10029 



PCT/US98/16813 



13/50 











§1 





















^ o 








o o 








z o 




o 






CO 


OWER 
NLET 


DO 













SUBSTITUTE SHEET (RULE 26) 



WO 99/10029 



PCT/US98/16813 



14/50 



PROCESSOR 
704 



MAIN MEMORY 
708 



702 



SECONDARY MEMORY 



BUS 
706 



HARD DISC DRIVE 
712 


710 






REMOVABLE STORAGE 
DRIVE 
714 




REMOVABLE STORAGE 
MEDIA 
720 








REMOVABLE STORAGE 
UNIT INTERFACE 
720 




REMOVABLE STORAGE 
UNIT 
722 





COMMUNICATIONS INTERFACE 
724 



CHANNEL 
728 



Fig. 19 

SUBSTITUTE SHEET (RULE 26) 



WO 99/10029 



PCT/US98/16813 



15/50 




Fig. 20 



Fig. 21 Fig. 22 



Fig. 23A 


Fig. 22B 


Fig.23C 


Fig. 23D 


Fig. 23 


Fig. 31A 


Fig. 31 B 


Fig.31C 


Fig. 31 






Fig. 33A 


Fig. 33B 


Fig. 33C 


Fig. 33 



Fig.24A 


Fig.24B 





Fig. 24 




Fig. 32A 




Fig. 35A 




Fig. 29 




Fig. 32B 




Fig. 35B 



SUBSTITUTE SHEET (RULE 26) 



WO 99/10029 



PCT/US98/16813 



16/50 



WTFM START-UP OVERVIEW 




Fig. 20A 



r 42 > 
RETURN TO 
START UP 
SCREEN. 
ERONT PANEL 
IS UNLOCKED 



SUBSTITUTE SHEET (RULE 26) 



17/50 



PCT/US98/16813 





. VIAL PORT 1 
\ SELECTED / 









LUER 
PORT 
SELECTED 



HASX 
MINUTES 

XPIRED S1NC 
LAST KEY 

EQUATION?/ 




SUBSTITUTE SHEET (RULE 26) 



WO 99/10029 



18/50 



PCT/US98/16813 




.05 



SUBSTITUTE SHEET (RULE 26) 



WO 99/10029 



PCT/US98/16813 




SUBSTITUTE SHEET (RULE 26) 



WO 99/10029 



PCT/US98/16813 



20/50 




SUBSTITUTE SHEET (RULE 26) 



WO 99/10029 



PCT/US98/16813 



21/50 




SUBSTITUTE SHEET (RULE 26) 



WO 99/10029 



PCT/US98/16813 



22/50 




SUBSTITUTE SHEET (RULE 26) 



WO 99/10029 



PCT/US98/16813 



23/50 




SUBSTITUTE SHEET (RULE 26) 



WO 99/10029 



PCT/US98/16813 




SUBSTITUTE SHEET (RULE 26) 



WO 99/10029 



PCT/US98/16813 



25/50 




SUBSTITUTE SHEET (RULE 26) 



WO 99/10029 



PCT/US98/16813 



VIAL ATTACHMENT ROUTINE 



26/50 



FIG. 24 A 




( 44 ^ 




' 45 ) 


RETURN TO 




GOTOTBO 


SCREEN 




DOSE ABORT 


I #12 J 




^ PROCDURE v 



46 \ 
DISPLAY "DRUG NAME l 
SCHEDULED FOR DELIVERY AT 
XX XX HAS BEEN ABORTED. 
THIS PORT IS NO LONGER 
AVAILABLE FOR USE" ) 



SUBSTITUTE SHEET (RULE 26) 



WO 99/10029 



PCMJS98/16813 




SUBSTITUTE SHEET (RULE 26) 



WO 99/10029 



PCT/US98/16813 




SUBSTITUTE SHEET (RULE 26) 



WO 99/10029 



PCT/US98/16813 



29/50 




SUBSTITUTE SHEET (RULE 26) 



WO 99/10029 



PCT/US98/16813 



30/50 




SUBSTITUTE SHEET (RULE 26) 



WO 99/10029 



31/50 



PCT/US98/16813 




SUBSTITUTE SHEET (RULE 26) 



WO 99/10029 



PCT/US98/16813 



32/50 




.2> 



SUBSTITUTE SHEET (RULE 26) 



WO 99/10029 



PCT/US98/16813 



33/50 




SUBSTITUTE SHEET (RULE 26) 



WO 99/10029 



PCT/US98/16813 



34/50 




SUBSTITUTE SHEET (RULE 26) 



WO 99/10029 



PCT/US98/16813 



35/50 




CO 



SUBSTITUTE SHEET (RULE 26) 



WO 99/10029 



PCT/US98/16813 



36/50 




SUBSTITUTE SHEET (RULE 26) 



WO 99/10029 



PCT/US98/16813 



37/50 




SUBSTITUTE SHEET (RULE 26) 



WO 99/10029 



PCT/US98/16813 



38/50 





SUBSTITUTE SHEET (RULE 26) 



WO 99/10029 



PCT/US98/16813 



VIAL PORT PROGRAMMING 39/50 
PASSWORD (OR UNIQUE NUMERIC CODE) ENTRY 



Fig. 32A-1 




CURRENT STATUS SCREEN 
DISPLAYS RUNNING AND 
SCHEDULING MESSAGES 
FOR EACH PORT 



VIAL PORT 
PROGRAM 
BUTTON 
\PRESSEI 




'SCAN BARCODE ON 
VIAL OR PRESS OK FOR 
DRUG PULL DOWN UST 
OR PRESS CANCEL TO 
EXIT" 



23 

GO TO DRUG PULL 
DOWN-LIST-SCREEN 
. J37 ^ 




20 

PULL UP PORT 
PROGRAM SCREEN 



THERE IS ALREADY A "DRUG 

NAME AND DOSAGE" 
SCHEDULE FOR DELIVERY AT 
xxxxx. PRESS OK TO 
SCHEDULE AN ADDITIONAL 
DELIVERY OR PRESS CANCEL TO 
RETURN TO EXIT I 




SUBSTITUTE SHEET (RULE 26) 



WO 99/10029 



40/50 



PC77US98/16813 



1 

ENTER CASSETTE 
PRIMING SEQUENCE 




r 2 

UPON COMPLETION OF 
CASSEnE PRIMING-RETURN 
, TO SCREEN |8 , 




THIS PORT IS CURRENTLY 1 
SCHEDULED FOR USE. PRESS 
OK TO VIEW SCHEDULING 
SCREEN OR PRESS 
CANCEL TO EXIT 




25 

PLEASE RESCAN 
BARCODE ON VIAL 




Fig. 32A-2 





r » 

GOTO 
t SCHEDUUNG SCREEN ^ 


> Y- 







18 

RETURN TO FRONT 
PANEL LOCKED 
CURRENT STATUS 
SCREEN 



RETURN TO CURRENT 
STATUS SCREEN 




26 

BARCODE SCAN FAILED 
TO SELECT DRUG FROli 
DRUG UST PRESS OK 
PRESS-CANCtLIO-EMT 




DISPLAY DRUG NAME 
AND DOSAGE "PRESS 
OK IF CORRECT. 
PRESS CANCEL f 
INCORRECT* 



34 

RETURN TO SCAN 
SCREEN f 16 




S THE SAME DRUG AND DOSE 
'ALREADY SCHEDULED FOR 

DELIVERY WITHIN 1B0 
TIME OF PROPOSED "DRUG 
NAME' DELIVERY TIME ON 
ANOTHER PORT? 




37 

/DISPLAY DRUG SELECTION UST H1H 
SUCESS BY SPECIFIC ALPHA 
USE CURSOR TO HIGHLIGHT DRUG 
CHOICE. THE PRESS OK. PRESS 
1f\ \ CANCEL TO EXIT 
CANCEL 



® 




SUBSTITUTE SHEET (RULE 26) 



WO 99/10029 



PCT/US98/16813 



41/50 




SUBSTITUTE SHEET (RULE 26) 



WO 99/10029 



PCT/US98/16813 




SUBSTITUTE SHEET (RULE 26) 



WO 99/10029 



PCT/US98/16813 



43/50 




SUBSTITUTE SHEET (RULE 26) 



WO 99/10029 



44/50 



PCTAJS98/16813 




SUBSTITUTE SHEET (RULE 26) 



WO 99/10029 



PCTAJS98/16813 



45/50 




SUBSTITUTE SHEET (RULE 26) 



WO 99/10029 

I IIFR PORT PROGRAMMING 



PCT/US98/16813 



46/50 



'display current luer port information and this message 

FOR X SECONDS OR UNTIL A NEW KEY ACTUATION"THE LUER PORT 
DELIVERY IS CURRENTLY IN PROGRESS. tHE LUER PORT WILL BE 
AVAILABLE FOR A NEW PROGRAM AT XX:XX 




DISPLAY SCHEDULED VIAL PROGRAM 
INFORMATION. CHANGES TO CHANGEABLE 
PARAMETERS CAN BE MADE. "LUER PORT IS SCHEDULED 
JO BE A DILUENT FOR DELIVERY OF 'DRUG NAME' ON PORT 
' H AT XXtXX. PRESS OKTO CONFIRM DELIVERY. PRESS 
CANCEL TO TO DISCONTINUE THIS PROGRAM 



DISPLAY SCHEDULED PROGRAM INFORMATION. 
CHANGES TO CHANGEABLE PARAMETERS CAN BE 
MADE. "LUER PORT DEUVERY IS SCHEDULED TO 
BEGIN AT XX:XX. PRESS OKTO CONFIRM DEUVERY. 
PRESS CANCEL TO DISCONTINUE THIS PROGRAM 



^ 42 > 
PORT PROGRAM REFLECTS ANY 
PARAMETER CHANGES MADE 
AND RETURNS TO CURRENT 
STATUS SCREEN y 




54 

PORT PROGRAM REFLECTS 
NO PARAMETER CHANGES 
MADE AND RETURNS TO 
FRONT PANEL LOCKED 
CURRENT STATUS 
SCREEN 



Fig. 35A-1 



<^ANCEL PRESSEOj> — 1 





46 

YOU HAVE SELECTED TO 
DISCONTINUE THE SCHEDULED 
DELIVERY OF 'DRUG NAME' ON 
(LUER OR VIAL) PORT T PRESS 
OK IF THIS IS CORRECT. PRESS 
CANCELTO RETURN TO PRIOR 
SCREEN. 



56 

PORT PROGRAM REFLECTS NO 
PARAMETER CHANGES MADE 
AND RETURNS TO FRONT PANEL 
LOCKED CURRENT STATUS 
SCREEN 



•Y 



SUBSTITUTE SHEET (RULE 26) 



WO 99/10029 



Fig. 35A-2 



PCT/US98/16813 



47/50 




'"VIAL PORT "X" MED. DELIVERY IS IN PROGRESS. 

BACK FLUSHING OF SECONDARY SET IS NOT 
POSSIBLE AT THIS TIME. PRESS OK FOR OPTIONS 
PRESS CANCEL WITHOUT BACK FLUSHING. 





13 

ENABLE BACK FLUSH KEY. 'TO BACK FLUSH 
SECONDARY SET PRESS AND HOLD BACK FLUSH 
KEY UNTIL LENGTH THIS MAY REQUIRE MORE THAN 
ONE PRESS AND HOLD. WHEN COMPLETE (MOVE 
CURSOR TO COMPLETE?) PRESS OK. PRESS CANCEL 
IF NO IF NO BACK FLUSHING IS REQUIRED 




L 








34 




RETURN TO 




PASSWORD 


1 


PROTECTED 




CURRENT 




STATUS SCREEN 



J 





HAS 'REQUIRE BARCODE SCAN \ 
FOR LUER PORT DELIVER' PREFERENCE V® 
BEEN SET ON PHARMACYPREFERENCE / 
SECTION / 

t 



32 

Y~ DISABLE BACK FLUSH 
VJ(EY AND TURN FLAG OFF, 






r 60 > 
GO TO FRONT PANEL LOCKED 
CURRENT STATUS SCREEN 
UPON FRONT PANEL ACCESS 
v RETURN TO #45 J 




45 

PROGRAMMED DELIVERY OF 'DRUG 
NAME' HAS BEEN DISCONTINUED. 
REMOVE 'DRUG NAME' FROM LUER 
PORT AND REMOVE FROM SCHEDULE. 
PRESS OKAY WHEN COMPLETE 



PROGRAMMED DELIVERY OF 'DRUG NAME' 
ON PORT -X' IS NOW PLACED ON HOLD. 
DELIVERY OF THIS DRUG MAY BE RESCHEDULED 
AT A LATER TIME. REMOVE 'DILUENT NAME' 
FROM LUER PORT. PRESS OK WHEN COMPLETE/ 



SUBSTITUTE SHEET (RULE 26) 



WO 99/10029 



PCT/US98/16813 



48/50 



® — Y- 



RETURN TO PASSWORD 
PROTECTED CURRENT 
STATUS SCREEN 



Fig. 35B 



<D — Y- 



RETURN TO FRONT 
PANEL LOCKED 
CURRENT STATUS 
SCREEN 



"YOU MAY REPLACE THE SECONDARY SET TO 
SCHEDULE THIS DELIVERY OR YOU WILL HAVE TO WAIT 
UNTILXHXTO RETURN. PRESS OK IF A NEW 
SECONDARY SET IS IN PLACE OR PRESS CANCEL TO 
EXIT. 




DISPLAY ON LCD "SCAN 
BARCODE ON LABEL IF NO 
BARCODE IS AVAILABLE, 
PRESS OK TO OVERRIDE 
BARCODE SCAN OR PRESS 
CANCEL TO EXIT" 






55 




RETURN TO FRONT 




PANEL LOCKED 




CURRENT STATUS 




SCREEN 



SUBSTITUTE SHEET (RULE 26) 



WO 99/10029 



49/50 



PCT/US98/16813 




66 

RETURN TO 
BARCODE SCAN 
SCREEN #27 



63 

DISPLAY DRUG NAME, DOSAGE, 
BLANK VOLUME, BLANK RATE, 
BLANK DURATION OE DELIVERY 
(RATE OR DURATION CAN BE 
CALCULATED WITH VOLUME AND 
ONE OF THESE TWO PARAMETERS), 
"USE CURSOR TO SELECT FIELDS 
AND INPUT VALUES. PRESS OK 
WHEN COMPLETE OR PRESS 
CANCEL TO EXIT J 



® 



Fig. 35 B-1 



SUBSTITUTE SHEET (RULE 26) 



WO 99/10029 



PCT/US98/16813 



50/50 




SUBSTITUTE SHEET (RULE 26) 



INTERNATIONAL SEARCH REPORT 



intfr. .ational Application No 

PCT/US 98/16813 



A. CLASSIFICATION OP SUBJECT MATTER 

IPC 6 A61M5/172 



According to International Patent Classification (IPC) or to both national classification and IPC 



B. FIELDS SEARCHED 



Minimum documentation searched (classification system followed by classification symbols) 

IPC 6 A61M 



Documentation searched other than minimum documentation to the extent that such documents are included in the fields searched 



Electronic data base consulted during the international search (name of data base and, where practical, search terms used) 



C. DOCUMENTS CONSIDERED TO BE RELEVANT 



Category ' Citation of document, wrth indication, where appropriate, of the relevant passages 



US 5 651 775 A (WALKER ET AL.) 
29 July 1997 



see column 5, line 3 - line 48 

see column 7, line 58 - column 10, line 65 

see column 12, line 51 - column 13, line 

34 

see column 14, line 38 - column 15, line 2 
see figures 1,2,10-13 

-/- 



Relevant to claim No. 



1-5, 

9-19, 

23-29, 

34-47, 

51-53 



Further documents are listed in the continuation of box C 



Patent family members are listed in annex. 



• Special categories of cited documents : 

"A" document defining the general state of the art which is not 

considered to be of particular relevance 
"E" earlier document but published on or after the international 

filing date 

V document which may throw doubts on priority daim(s) or 
which is cited to establish the publication date of another 
citation or other special reason (as specified) 

"O" document referring to an oral disclosure, use, exhibition or 
other means 

"P" document published prior to the international filing date but 
later than the priority date claimed 



T later document published after the international filing date 
or priority date and not in conflict with the application but 
cited to understand the principle or theory underlying the 
Invention 

"X" document of particular relevance; the claimed invention 
cannot be considered novel or cannot be considered to 
involve an inventive step when the document is taken alone 

"Y" document of particular relevance; the claimed invention 

cannot be considered to involve an inventive step when the 
document is combined with one or more other such docu- 
ments, such combination being obvious to a person skilled 
in the art 

document member of the same patent family 



Date ot the actual completion ot theintemational search 



20 November 1998 



Date of mailing of the international search report 



27/11/1998 



Name and mailing address of the ISA 

European Patent Office. P.B. 5818 Patentlaan 2 
NL - 2280 HV Rijswtjk 
Tel. (+31-70) 340-2040. Tx. 31 551 epo nl. 
Fax: (+01-70) 340-3016 



Authorized officer 



Schonleben, 0 



Form PCT/iSA/210 (second sheet) (July 1992) 



page 1 of 2 



INTERNATIONAL SEARCH REPORT 


Inte. . .ational Application No 

PCT/US 98/16813 j 


| C.(Continuation) DOCUMENTS CONSIDERED TO BE RELEVANT 




1 Category ( 


Station of document, with indication.where appropriate, ot the relevant passages 


elevant to claim No. \ 


1 x 

X 

X 
A 


US 4 624 661 A (ARIMOND) 25 November 1986 

see column 6, line 19 - column 7, line 45 
see figures 1-3 

US 4 573 994 A (FISCHELL ET AL.) 
4 March 1986 

see column 9, line 22 - column 10, line 61 
see figures 3,6 

FR 2 717 919 A (ENSYMA) 29 September 1995 
see the whole document 

WO 94 12235 A (ABBOTT LABORATORIES) 
9 June 1994 

see page 3, line 1 - page 4, line 27 
see page 5, line 1 - page 7, line 3 
see page 10, line 7 - page 11, line 10 
see page 12, line 6 - page 13, line 17 
see page 16, line 6 - line 17 
see figures 1,2 


1,2, 

9-12,15, 
23, 

26-28, 1 

30,31, 

34,35, 

37-40, | 
43,51 

1,2,4, 
15,16, 
22,26, 
34,35, 

43,44,50 J 
1,26 

1-3,6,7, 
9-11, 

13-15, ! 
19-21 , 
23,26, 

30-39 , j 

41-43, 

47-49,51 



Form PC171SA/210 (continuation of second sheet) (July 1992) 

page 2 of 2 



INTERNATIONAL SEARCH REPORT 



international application No. 

PCT/US 98/16813 



Box I Observations where certain claims were found unsearchable (Continuation of item 1 of first sheet) 



This International Search Report has not been established in respect of certain claims under Article 17(2)(a> for the following reasons: 

1. jjjT] Claims Nos.: 54-69 

because they relate to subject matter not required to be searched by this Authority, namely: 

Rule 93.1(iv) PCT - Method for treatment of the human or animal body 
by therapy. 

2. Claims Nos.: 

because they relate to parts of the International Application that do not comply with the prescribed requirements tosuch 
an extent that no meaningful International Search can be carried out. specifically: 



3. Q Claims Nos.: 

because they are dependent claims and are not dratted in accordance with the second and third sentences of Rule6.4(a>. 



Box II Observations where unity of invention is lacking (Continuation of item 2 of first sheet) 



This international Searching Authority found multiple inventions in this international application, as follows: 



1 I j As alt lequned additional search fees were timely paid by the applicant, this international Search Report covers all 
1 — 1 searchable claims. 



2. | | As all searchable claims could be searched without effort justifying an additional fee. this Authority did not invite payment 
of any additional fee. 



3. I I As only some of the required additional search fees were timely paid by the applicant, this International Search Report 
1 — » covers only those claims for which fees were paid, specif tcalty claims Nos.: 



4. 1 | No required additional search tees were timely paid by the applicant. Consequently, this International Search Report is 
restricted to the invention first mentioned in the claims: it is covered by claims Nos.: 



Remark on Protest The additional search tees were accompanied by the applicant's protest. 

| | No protest accompanied the payment of additional search tees. 
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